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Notices 
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Programming Interface Information 


This book is intended to help applicaton programmers use the SNMP function of the IBM OS/400 licensed 
program. This book documents General-Use Programming Interface and Associated Guidance Informa- 
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OS/400 licensed program. 
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About Simple Network Management Protocol (SNMP) Support 


(SC41-5412) 


This book is intended for the administrator who is 
responsible for configuring SNMP related systems 
management function in OS/400. Itis also a 
guide for the programmer who intends to write 
SNMP managing applications or SNMP suba- 
gents. 


SNMP support in the AS/400 system includes the 
following: 


¢ Configuring and using the SNMP agent 

¢ Configuring and using TRAP manager support 
e Using client inventory management 

e Using the SNMP subagent DPI API. 


Using this book, the AS/400 programmer can: 


¢ Configure the AS/400 system to use SNMP 
support 

e¢ Create SNMP subagents that can respond to 
SNMP managing applications 

¢ Create managing applications that can request 
information from appropriate SNMP suba- 
gents. 


You should be familiar with the following to use 
the information in this book: 


¢ AS/400 programming terminology. You 
should also be familiar with the terminology of 
the host system. 


¢ Data communications concepts. 
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Prerequisite and Related 
Information 


For information about other AS/400 publications 
(except Advanced 36), see either of the following: 


e¢ The Publications Reference book, SC41-5003, 
in the AS/400 Softcopy Library. 

¢ The AS/400 Information Directory, a unique, 
multimedia interface to a searchable database 
that contains descriptions of titles available 
from IBM or from selected other publishers. 
The AS/400 Information Directory is shipped 
with the OS/400 operating system at no 
charge. 


Information Available on the 
World Wide Web 


More AS/400 information is available on the World 
Wide Web. You can access this information from 
the AS/400 home page, which is at the following 
uniform resource locator (URL) address: 


http://www.as400.ibm.com 
Select the Information Desk, and you will be able 


to access a variety of AS/400 information topics 
from that page. 
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Chapter 1. Introduction to SNMP for OS/400 


This chapter describes the Simple Network Man- 
agement Protocol (SNMP), SNMP components 
(manager, agent, subagent), and Management 
Information Bases (MIBs) related to SNMP. The 
implementation of SNMP for OS/400 is also dis- 
cussed. 


Definition of Simple Network 
Management Protocol (SNMP) 


Simple Network Management Protocol (SNMP) 
is an industry standard management protocol that 
originated for TCP/IP networks. SNMP is 
described by a series of Request for Comments 
(RFCs) that specifies and structures the informa- 
tion that is exchanged between managing and 
managed systems. SNMP is used predominately 
in TCP/IP networks. However, OS/400 AnyNet 
support allows OS/400 SNMP support to be used 
in a SNA network. 


Definition of SNMP Agent 


SNMP agenis reside on systems that are 
managed. The agent receives requests to either 
retrieve or change management information by 
referencing MIB objects. Management Informa- 
tion Base (MIB) objects are units of information 
that provide information about the system and the 
network to the managing system. MIB objects are 
referenced by the agent whenever a valid request 
from an SNMP manager is received. 


Definition of SNMP Manager 


An SNMP manager refers to a system that runs a 
managing application or suite of applications. 

These applications depend on MIB objects for 

information that resides on the managed systems. 
Managers generate requests for this MIB informa- 
tion, and an SNMP agent on the managed system 
responds to these requests. A request can either 
be the retrieval or modification of MIB information. 


By accessing the MIB objects, the SNMP agent 
allows configuration, performance, and problem 
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management data to be managed by the SNMP 
manager. This is how the agent makes network 
and system information available to other systems. 


For example, a managing application that displays 
system descriptions can be running on a NetView 
for AIX management platform. If a user needs to 
access the AS/400 description, the managing 
application constructs a message that requests a 
MIB object called sysDescr. This request is sent 
to the AS/400 system where the SNMP agent 
decodes the message and then retrieves the infor- 
mation from the sysDescr MIB object. The agent 
constructs a response with this information and 
sends it back to the managing application. When 
the application has decoded the response, the 
SNMP manager can then display the AS/400 
description information to the user. 


You can use both the SNMP manager APIs and 
the SNMP trap support to write an SNMP man- 
agement application on an AS/400 system. You 
can retrieve and set MIB data by using the SNMP 
manager APIs. You can monitor for unsolicited 
SNMP trap messages by using the SNMP trap 
support. For a more detailed description of the 
OS/400 SNMP manager APIs, along with sample 
source code, see “Simple Network Management 
Protocol (SNMP) Manager APIs” in the book 
System API Reference: UNIX-Type APIs. 


Definition of SNMP Subagents 


SNMP agents have predefined MIB objects that 
they can access. This limits the manager in 
regards to the type of information that it can 
request. The need to overcome this limitation 
brought about the introduction of subagents. A 
subagent allows the dynamic addition of other 
MIB objects without the need to change the agent. 
At the same time, SNMP managers are not 
impacted by these dynamic additions because 
they continue to work directly with the SNMP 
agent. Therefore, an SNMP management applica- 
tion can choose to work as if the MIB objects 
came directly from the SNMP agent. 
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MIB Objects Supported by the 
AS/400 SNMP Agent 


MIB objects are units of managed information 
that specifically describe an aspect of a system 
such as the system name, hardware number, or 
communication configuration. A collection of 
related MIB objects is defined as a MIB. The fol- 
lowing are the main MIBs that are supported by 
OS/400. 


Standard RFC MIBs 


¢ MIB II (RFC1213) 

e Ethernet-like (RFC1398) 
¢ FDDI (RFC1285) 

e Frame Relay (RFC1315) 
¢ Token Ring (RFC1231) 


IBM enterprise MIBs 


e APPN MIB 

¢ Client Management MIB 

e NetView for AIX subagent MIB 
e¢ DPI 2.0 (RFC1592) 

¢ SNMP subagent MIB 


All of the IBM enterprise MIBs except for DPI 2.0 
are provided in QSYS/QANMMIB. The DPI 2.0 
MIB is not used in OS/400. For more specific 


information concerning the supported MIBs associ- 


ated with SNMP, refer to Appendix A, “OS/400 
SNMP Agent Set Processing and Supported 
SNMP MIBs.” 


Figure 1-1 provides a general overview of the 
SNMP components and how they reference MIBs. 
Responses, requests, and traps are discussed in 
the next section. 


Requests 
Responses Manager 
Traps 
Managing System 
> AS/400 
Agent MIBs 
Requests i 
Responses 
Subagent MIBs 
Managed System 
RV3P151-2 


Figure 1-1. SNMP Overview 


Supported SNMP Protocol 
Elements 


The OS/400 SNMP and MIB implementations are 
based on the following Internet RFCs: 


e RFC1157 Simple Network Management Pro- 
tocol (SNMP) 


e RFC1155 Structure and Identification of Man- 
agement Information for TCP/IP-based Inter- 
nets 


e RFC1212 Concise MIB Definition 


e RFC1213 Management Information Base for 
Network Management of TCP/IP-based Inter- 
nets: MIB-II 


e RFC1215 Convention for Defining Traps for 
Use with SNMP 


e RFC1720 IAB Official Protocol Standards 
e RFC1700 Assigned Numbers 
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e RFC1592 Distributed Protocol Interface (DPI) 
2.0 


The type of protocol used by SNMP to pass data 
between the SNMP manager and the SNMP agent 
is a request/response protocol. The manager 
makes a request for MIB object information and 
the agent responds to that request. SNMP uses 
five protocol operations to implement this type of 
protocol: 


1. GET - Request to inspect one or more MIB 
objects 


2. GETNEXT - Request to inspect the next MIB 
object 


3. SET - Request to alter the value of one or 
more MIB objects 


4. RESPONSE - Response to a GET, 
GETNEXT, or SET request. 


1 A protocol data unit (PDU) is a protocol unit of work. 


5. TRAPS - Unsolicited messages. Including: 
coldStart, warmStart, linkDown, linkUp, 
authenticationFailure, EGPNeighborLoss, and 
enterpriseSpecific. 


The GET, GETNEXT, and SET requests are 
issued by the SNMP manager to the SNMP agent. 
The RESPONSE request is issued by the agent to 
the manager. TRAPS are sent from the agent to 
one or more managers as unsolicited messages. 


As an example: an SNMP manager requests con- 
figuration information for a particular system. The 
manager formats this request in a GET protocol 
data unit (PDU)' and transmits the request to the 
agent using a communication service. After the 
manager's request has been received, the agent 
packages the requested MIB object information in 
a RESPONSE PDU and transmits it back to the 
manager. 
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Part 1. Configuring and Using SNMP 
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Chapter 2. Configuring the OS/400 SNMP Agent 


This chapter describes how to configure the 
OS/400 SNMP agent. SNMP agent configuration 
on the AS/400 consists of the following sections: 


¢ Communities: You need to describe how 
communities are used so that the SNMP 
agent can determine which SNMP manager 
requests to honor. 


¢ SNMP Agent Attributes: You need to 
describe the values and options that are used 
by the SNMP agent, including the destination 
SNMP managers for traps generated by the 
agent. 


Communities 


The relationship between a SNMP agent and one 
or more SNMP managers is controlled by using 
communities. Each community consists of the fol- 
lowing elements: 


community name 
Specifies the name of a community. The 
SNMP manager must specify a community 
name that is recognizable to the SNMP agent 
so the agent can honor the manager's 
request. 


object access specification 
Specifies what operations the SNMP man- 
agers are allowed to perform. 


list of SNMP managers’ IP addresses 
The SNMP manager must specify an IP 
address that is recognizable to the SNMP 
agent so that the agent can honor the manag- 
er's request. 


Community Naming Conventions 


A community name consists of one or more char- 
acters. Typically, community names consist of 
readable characters. They can also consist of 
non-readable characters. These non-readable 
characters can take on any value between X'00' 
and X'FF'. Because of possible non-readable 
characters, the Add Community for SNMP 
(ADDCOMSNMP), Change Community for SNMP 
(CHGCOMSNMP), and Remove Community for 
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SNMP (RMVCOMSNMP) commands have an 
additional parameter; translate community name 
(ASCIICOM). ASCIICOM determines whether a 
community name is translated to ASCII characters 
before it is compared with the community name in 
a received SNMP manager's request. The 
ASCIICOM parameter has two possible values, 
“YES and *NO. Most of the time 
ASCIICOM(*YES) is specified. If a community 
specifies ASCIICOM(*YES), the SNMP agent 
translates the community name from EBCDIC to 
ASCII characters before comparing it with the 
community name specified in the SNMP manager 
request. This feature ensures compatibility 
between an AS/400 system (an EBCDIC system) 
and ASCII managers. ASCIICOM(*NO) is speci- 
fied only if the managing system sends community 
names in EBCDIC or if the community name con- 
sists of one or more non-readable characters. 
When ASCIICOM(*NO) is specified, translation 
does not occur. 


The combination of the community name and the 
ASCIICOM value identifies a community in 
OS/400. For example, community ‘public’ 
ASCIICOM(*YES) and community ‘public’ 
ASCIICOM(*NO) are two different communities. 


Object Access Specification 


Object access for a community is specified on the 
ADDCOMSNMP and CHGCOMSNMP commands 
by the OBJACC parameter. The OBJACC param- 
eter contains one of four values: 


*READ 
managers in this community can access all 
readable objects for all MIB groups. 


*WRITE 
managers in this community can access all 
readable MIB objects and can change all 
changeable MIB objects. 


*NONE 
managers in this community cannot access 
any MIB objects. 


Note: This value can be used to temporarily 
deny access to managers in a commu- 
nity without removing the community. 
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*SNMPATR 
the community is to use the object access 
value specified in the SNMP attributes. 


Manager List 


The list of SNMP managers in the community is 
specified by the manager Internet address 
(INTNETADR) parameter on the ADDCOMSNMP 
and CHGCOMSNMP commands. This list con- 
sists of the IP addresses of the managers in the 
community. 


A special value of “ANY is supported on the 
INTNETADR parameter for the ADDCOMSNMP 
and CHGCOMSNMP commands. This value indi- 
cates that all SNMP managers in the network 
could be part of this community. 


OS/400 Community Attributes 


For OS/400, a community has two additional attri- 
butes: 


¢ LOGSET (log set request) - controls the 
logging of SET requests in journal QSNMP in 
library QUSRSYS, and 


¢ LOGGET (log get request) - controls the 
logging of GET and GETNEXT requests in 
journal QSNMP in library QUSRSYS. 


Each of the community logging parameters has 
three possible values: 


*YES 
manager's requests are logged in the journal. 


*NO 
manager's requests are not logged. 
*SNMPATR 


the logging value specified in the SNMP attri- 
butes is to be used for that community. 


For more information on SNMP logging, refer to 
Appendix B, “Journal for SNMP Logging” on 
page B-1. 


Procedures for Configuring a 
Community 


New communities are defined and added to the 
OS/400 SNMP agent configuration information by 
either: 


e Issuing the ADDCOMSNMP command 


¢ Selecting option 1 on the Work with Communi- 
ties for SNMP display. This work with display 
is shown by selecting option 2 after entering 
the Configure TCP/IP SNMP (CFGTCPSNMP) 
command. 


Existing communities are changed by either: 
¢ Issuing the CHGCOMSNMP command 


¢ Selecting option 2 on the Work with Communi- 
ties for SNMP display. This work with display 
is shown by selecting option 2 after entering 
the Configure TCP/IP SNMP (CFGTCPSNMP) 
command. 


Existing communities can be removed by either 
e Issuing the RMVCOMSNMP command 


¢ Selecting option 4 on the Work with Communi- 
ties for SNMP display. This work with display 
is shown by selecting option 2 after entering 
the Configure TCP/IP SNMP (CFGTCPSNMP) 
command. 


Existing communities can be listed by using the 
Work with Communities for SNMP display. This 
display is shown by selecting option 2 after 
entering the CFGTCPSNMP command. The attri- 
butes of a single community can be shown by 
selecting option 5 on the Work with Communities 
for SNMP display. 


SNMP Agent Attributes 


SNMP agent attributes are specified on the 
AS/400 by either: 


e Running the CHGSNMPA command 


¢ Selecting option 1 on the Configure TCP/IP 
SNMP menu display that is shown by running 
the CFGTCPSNMP command. 


The following are parameters which are used 
when specifying an SNMP agent on the AS/400 
system. 


System Contact Parameter 


This parameter corresponds to the sysContact 
MIB object of MIB-II. When *CNTINF is specified, 
the system contact is set to the local system 
contact value specified on the Work with Support 
Contact Information (WRKCNTINF) command 
(option 2 - Work with local service information). 
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This value can be changed by a manager that is 
part of a community that specifies *WRITE 
access. It can also be read by a manager that is 
part of a community that specifies ~READ or 
“WRITE access. 


System Location Parameter 


This parameter corresponds to the sysLocation 
MIB object of MIB-II. When *CNTINF is specified, 
the system location is set to the local system 
location value specified on the WRKCNTINF 
command (option 2 - Work with local service infor- 
mation). This value can be changed by a 
manager that is part of a community that specifies 
“WRITE access. It can also be read by a 
manager that is part of a community that specifies 
“READ or “WRITE access. 


Send Authentication Traps 
Parameter 


This parameter corresponds to the 
snmpEnableAuthenTraps MIB object of MIB-II. 
Send Authentication Traps has a value of either 
“YES or *NO. 


*YES 
An authenticationFailure trap is sent to the 
managers defined in the trap managers attri- 
bute each time a request is received from an 
SNMP manager with a community name that 
is unknown to the SNMP agent. 


*NO 
No authenticationFailure traps will be sent. 


This value can be changed by a manager that is 
part of a community that specifies *WRITE 
access. It can also be read by a manager that is 
part of a community that specifies ~READ or 
“WRITE access. 


Automatic Start Parameter 


This parameter controls whether the SNMP agent 
is started when the Start TCP/IP (STRTCP) 
command runs. 


*YES 
The SNMP agent is started. 


*NO 
The SNMP agent is not started. 


Note: The Start TCP Server (STRTCPSVR) 
command must be used to start the SNMP agent 
in this case. 


Object Access and the Logging 
Requests Parameters 


The object access, log set request, and the log 
get request function the same way as their com- 
munity parameter counterparts. 


Log Traps Parameter 


This parameter has the following values: 


*YES 
A log entry is added to the QSNMP journal in 
the QUSRSYS library when the SNMP agent 
sends a trap. 


*NO 
Trap logging does not occur. 


Trap Manager Parameter 


This parameter specifies which SNMP managers 
are sent the OS/400 SNMP agent's generated 
traps. Depending on the length of each element 
in the manager's list, up to 300 managers can be 
specified. Each element of the manager's list con- 
sists of three parts: 


e The contents of the manager's IP address. 
Note: This address must be unique. 


e¢ The community name that the agent puts in 
the trap before it is sent to the manager. 


Note: This name is completely independent 
from the community names that the agent 
uses to verify requests from a manager. 


e An indication of whether the community name 
should be translated to ASCII characters 
before it is placed into the trap. The same 
translation rules used for community names 


apply. 
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Pre-Configured Community 
Attributes 


The OS/400 system is shipped with the SNMP 
agent pre-configured and with one pre-configured 
community. 


community name public 
ASCIICOM *YES 
INTNETADR “ANY 
OBJACC “READ 
LOGSET *NO 
LOGGET *NO 


The pre-configured SNMP agent has the following 
attributes: 


system contact “NONE 
system location “NONE 
send authentication traps *YES 


autostart *“NO 
object access *READ 
log set requests *“NO 
log get requests *NO 
log traps *NO 
trap managers “NONE 


Configuring Your System for 
SNMP 


The following commands start and stop the SNMP 
agent. The OS/400 subagent starts and ends in 
parallel with the agent. 


STRTCPSVR (*SNMP) - Starts TCP/IP SNMP 
agent 


ENDTCPSVR (*SNMP) - Ends TCP/IP SNMP 
agent 
The following commands change the SNMP con- 
figuration: 
e¢ Add Community for SNMP - ADDCOMSNMP 
¢ Configure TCP/IP for SNMP - CFGTCPSNMP 


¢ Change Community for SNMP - 
CHGCOMSNMP 


e Change SNMP Attributes - CHGSNMPA 


e Remove Community for SNMP - 
RMVCOMSNMP 


The following are descriptions and examples of 
the preceding configuration commands. Of 
course, specific parameters would depend on your 


system's specific requirements. For additional 
information on these commands, see Appendix D, 
“CL Commands for AS/400 SNMP” on page D-1. 


ADDCOMSNMP (Add Community 
for SNMP) Command 


The Add Community for SNMP (ADDCOMSNMP) 
command allows the user to add an SNMP com- 
munity profile to the SNMP agent configuration 
file. An SNMP agent uses a community profile to 
determine whether or not to honor a request sent 
by an SNMP manager. 


This example adds community ‘ourcommunity' to 
the SNMP agent configuration file. The SNMP 
managers with the Internet addresses '8.6.5.4' and 
'8.6.5.3' are the only managers in the community 
(with set capability) and are able to change MIB 
objects. 


ADDCOMSNMP COM('ourcommunity') OBJACC(*WRITE) 
INTNETADR('8.6.5.4' '8.6.5.3') 


Note: It is important to check to see if the 
manager has multiple IP addresses. If the 
manager has multiple addresses, use the same IP 
address that the manager uses to send PDUs or 
enter all the hosts IP addresses for the manager's 
community. 


CHGCOMSNMP (Change 
Community for SNMP) Command 


The Change Community for SNMP 
(CHGCOMSNMP) command allows the user to 
change an SNMP community profile in the SNMP 
agent configuration file. 


This example changes community 'ourcommunity' 
in the SNMP agent configuration file. 


CHGCOMSNMP COM('ourcommunity') OBJACC(*READ) 


RMVCOMSNMP (Remove 
Community for SNMP) Command 


The Remove Community for SNMP 
(RMVCOMSNMP) command allows the user to 
remove an SNMP community profile from the 
SNMP agent configuration file. 


This command removes community 
(‘(ourcommunity') from the SNMP agent configura- 
tion file. 


2-4 0S/400 Simple Network Management Protocol (SNMP) Support V4R1 


RMVCOMSNMP COM('ourcommunity') 


CHGSNMPA (Change SNMP 
Attributes) Command 


The Change SNMP Attributes (CHGSNMPA) 
command allows the user to change values and 
options used by the SNMP agent. 


This example changes the system contact infor- 
mation and specifies that the SNMP agent should 
not start when the STRTCP command runs. 


CHGSNMPA SYSCONTACT('Joe Smith, telephone 555-1212') 


AUTOSTART (*NO) 


CFGTCPSNMP (Configure TCP/IP 
for SNMP) Command 


The Configure TCP/IP for SNMP (CFGTCPSNMP) 
command is used to display a menu that allows a 
user to define or change the SNMP configuration. 


This command presents the following series of 
menus that are used to define or change your 
SNMP configuration. 


CFGTCPSNMP 


Configure TCP/IP SNMP 
System: — ENDAS003 
Select one of the following: 


1. Change SNMP attributes 
2. Work with communities for SNMP 


Selection or command 
=e=> 


F3=Exit F4=Prompt F9=Retrieve F12=Cancel 
(C) COPYRIGHT IBM CORP. 


L 5 


Figure 2-1. CFGTCPSNMP main menu 


Option 1 of the Configure TCP/IP SNMP menu 
displays the Change SNMP Attributes 
(CHGSNMPA) command in prompt mode. 


Option 2 causes the Work with Communities for 
SNMP display to be shown. 


Work with Communities for SNMP 


Display: Option 2 of the Configure TCP/IP 
SNMP menu causes the following display to be 
shown: 


Work with Communities for SNMP 
System: — ENDAS003 
Type options, press Enter. 
1=Add 2=Change 4=Remove 5=Display 


Option Community Name 


Payroll 
Finance 
Engineering 
Accounting 


More... 
F3=Exit F5=Refresh F6=Print list F12=Cancel F17=Top  F18=Bottom 


ee 


Figure 2-2. Work with Communities for SNMP display 


Option 1 of the Work with Communities for SNMP 
display shows the ADDCOMSNMP command in 
prompt mode. 


Option 2 of the Work with Communities for SNMP 
display shows the CHGCOMSNMP command in 
prompt mode. 


Option 4 is used to remove a community. It 
causes the Confirm Remove of Communities for 
SNMP display to be shown. 


Option 5 is used to display detailed community 
information. It causes the Display Community for 
SNMP display to be shown. 


Pressing F6 causes detailed community informa- 
tion to be printed for all communities. 


Confirm Remove of Communities for 


SNMP Display: Option 4 causes the Work 
with Communities for SNMP display to be shown: 
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Confirm Remove of Communities for SNMP 
System: — ENDAS003 
Press Enter to confirm your choices for 4=Remove. 
Press F12 to return to change your choices. 


Option Community Name 
4 badcommunity 


4 badcommunity2 
4 badcommunity3 


Bottom 
F12=Cancel 


L J 


Figure 2-3. Confirm Remove of Communities for 
SNMP display 


Pressing enter causes the RUVCOMSNMP 
command to be run for each entry in the list. 


Display Community for SNMP 


Display: Option 5 causes the Work with Com- 
munities for SNMP display to be shown: 


Display Community for SNMP 


Community name... 2... ee ee 


Objectuaccess:. sc we se es 
Log set requests... . 2.2.02 5 
Log get requests... . 2.2.22 5 


Translate community name 


Manager Manager 
Internet Internet 
Address Address 
8.145.150.129 8.145.150.134 
8.145.150.130 8.145.150.135 
8.145.150.131 8.145.150.136 
8.145.150.132 8.145.150.137 
8.145.150.133 8.145.150.138 
Bottom 


Press Enter to continue. 


F3=Exit F12=Cancel 


wont eae pUb1A¢; 


Manager 
Internet 
Address 
8.145.150.139 
8.145.150.140 
8.145.150.141 
8.145.150.142 
8.145.150.143 


System:  ENDASO03 


Manager 
Internet 
Address 
8.145.150.144 


J 


Figure 2-4. Display Community for SNMP display 
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Chapter 3. SNMP Manager Enablement 


This chapter describes how the SNMP manager is 
enabled for OS/400. 


The OS/400 SNMP manager provides a rudimen- 
tary base for SNMP management applications. 
The OS/400 SNMP manager consists of the fol- 
lowing functions: 


¢ SNMP manager application program interface 
(API) 
e Trap manager 


SNMP Manager APIs 


The SNMP manager APIs provide SNMP manage- 
ment applications the ability to perform SNMP 
management functions (GET, GETNEXT, and 
SET) to local or remote SNMP agents. For addi- 
tional information on these APIs, see “Simple 
Network Management Protocol (SNMP) Manager 
APIs” in the book System API Reference: 
UNIX-Type APIs. 


Trap Manager 


The trap manager receives traps, parses traps, 
and then enqueues the traps to an internal queue. 
If configured to do so, the trap manager then 
sends the traps to other management destinations 
as they are configured in the SNMP agent on the 
AS/400 system. This type of function gives users 
the ability to decide whether to forward traps that 
are received from other nodes. The traps are for- 
warded through the SNMP agent that generates 
and sends the actual trap PDU. Therefore, traps 
are sent to all managers that are configured in the 
SNMP agent's trap manager attributes. Trap for- 
warding is configurable using a CL command 
interface. 


Note: Use care when configuring the trap desti- 
nations to avoid trap loops. (Loops are caused 
when two or more trap managers are configured 
to forward traps to each other.) 


The following is a list of trap manager commands: 


¢ STRTIRPMGR - Start trap manager 
e ENDTRPMGR - End trap manager 
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STRTRPMGR (Start Trap 
Manager) Command 


The Start Trap Manager (STRTRPMGR) 
command allows the user to start the OS/400 
SNMP trap manager job. An optional Forward 
Trap parameter may be specified. This parameter 
enables all traps received on port 162 of this 
system to be forwarded to the SNMP managers 
listed in the SNMP agent's trap manager attribute. 
When configuring the SNMP agent's trap manager 
attribute and specifying forwarding on in the 
STRTRPMGR command, refer to Appendix C, 
“Problem Analysis for SNMP” on page C-1. 


This example starts the trap management job. 
Traps that are received by the trap manager are 
enqueued and forwarded. 


STRTRPMGR FWDTRP(*YES) 
The other valid value for the FWDTRP parameter 
is *NO. For additional information on the 


STRTRPMGR command, see “STRTRPMGR 
(Start Trap Manager) Command” on page D-13. 


ENDTRPMGR (End Trap Manager) 
Command 


The End Trap Manager (ENDTRPMGR) command 
allows the user to end the OS/400 SNMP trap 
manager job. 


This example ends the trap management job. 
ENDTRPMGR 


SNMP Trap Support 


You can monitor for unsolicited SNMP trap mes- 
sages by using the SNMP trap support. These 
trap messages may contain helpful data for man- 
aging a network. 


By using the OS/400 SNMP manager, it is pos- 
sible to deliver SNMP traps to data queues. All 
traps that are received on an AS/400 system can 
be routed to user-defined data queues. For addi- 
tional information on configuring and using trap 
support, see “SNMP Trap Support” in the book 
System API Reference: UNIX-Type APIs. 


3-1 
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Chapter 4. Client Inventory Management 


Client Inventory Management can be used to 
provide the host with information about the client. 
If a client is configured to send SNMP traps to a 
managing AS/400, the host collects hardware, 
software, and connectivity information from the 
managed client. This chapter describes the Client 
Inventory Management and lists the Client Man- 
agement database formats. 


Client Inventory Management 


OS/400 gathers information about personal com- 
puter clients that are attached to the AS/400. The 
information is stored in AS/400 database files to 
provide a comprehensive inventory of personal 
computer assets. An example of the type of infor- 
mation available is the following: 


e Directory - connectivity, access, and manage- 
ment information 


¢ Software - installed software identification and 
change information 


¢ Hardware - disk drive, memory, hard file 


Traps that are received by an AS/400 system are 
processed differently for new clients than traps 
that are received for existing clients. New client's 
traps are processed immediately and are added 
for inventory management. Hardware and soft- 
ware information about this client is retrieved and 
stored in the database. 


For existing clients, hardware and software infor- 
mation is only refreshed if this information is more 
than 30 days old. 30 days is the default value. 
The default value can be changed to any value 
between 1 and 365 days. Any other value results 
in default of 30 days. A data area QZCAREFI in 
library QUSRSYS should be created to change 
the refresh interval. For example: 


CRTDTAARA DTAARA(QUSRSYS/QZCAREFI) 
TYPE(*DEC) LEN(2 0) VALUE(99) 
TEXT('Refresh Interval') 


This example sets the refresh interval at 99 days. 
The data area must be of type decimal (integer 
value). Using this example, a refresh interval of 
99 days is used for all clients that the AS/400 
system is managing. 


Using the Client Management MIB, users can 
write application programs that perform resource, 
asset, license, and network management functions 
by accessing the information in the Client Man- 
agement Databases.’ The Client Management 
Databases, which are a set of physical and logical 
files, represent the client information that was 
gathered using SNMP GET and GETNEXT 
requests when the client was connected to an 
AS/400. The database structure is based on the 
MIB objects that are being shadowed from the 
client. 


APls are provided to manage the clients in the 
Client Information Database. Using these APIs 
you can add, change, or remove client information 
that is stored on the client. 


Client Software Management 
Database Formats 


The following are the database formats used when 
querying and writing applications that access client 
management information. All of these database 
files are shipped with OS/400 in library QSYS. 
The files are copied into the QUSRSYS library 
when the first client is discovered and stored in 
the database. All client information is stored in 
the database files in the QUSRSYS library. The 
files in the QSYS library are for recovery pur- 
poses. 


1 The user is not able to write information to the databases. They are able to write programs that access the databases. 


© Copyright IBM Corp. 1997 


4-1 


QAZCADEV 


wk Start of specifications ee ee ee 


File Name: qazcadev 
File Type: physical 


Function: Database file where the client device 
information is maintained. The data is obtained 
from the HOST MIB. 


ZCAIDX --> Client Index 
ZCADEV --> Device Index 
ZCATYP --> Device Type 
ZCADID --> Device ID 

ZCASTT --> Device Status 
ZCAERR --> Device Errors 
ZCADSC --> Device Description 


e+ HF HF HF HF FF HH HF HF H F 


* 
* 
* 


End of Specifications KKK K AKA KK KR KKK IKI KAKA EKER KER ER ARK 
UNIQUE 
R QZCADEVR 
ZCAIDX 12H 
ZCADEV 9B 
ZCATYP 9B 
ZCADID 128A VARLEN (128) 
ZCASTT 9B 
ZCAERR 9B 
ZCADSC 64A VARLEN (64) 
ZCAIDX 
ZCADEV 


nAwzA 


QAZCADIR 


tek Start of specifications oe Se Se ee ee 


* 

* File Name: gqazcadir 

* File Type: physical 

* 

* Function: Database file where the basic client directory 

* information is maintained. 

* 

* ZCBIDX --> Client Index 

* ZCBCLT --> Client ID 

* ZCBDSC --> Client Description 

* ZCBCMN --> Community 

* ZCBIPA --> IP Address 

* ZCBCPN --> CP NetID 

* 

Wek End of Specifications OS eS ee 

UNIQUE 
R QZCADIRR 
ZCBIDX 12H 
ZCBCLT 255A VARLEN(255) 
ZCBDSC 255A VARLEN(255) 
ZCBCMN 255A VARLEN(255) 
ZCBIPA 15A VARLEN(15) 
ZCBCPN 17A VARLEN(17) 
K ZCBIDX 


QAZCADSK 


tek Start of specifications HII KKK II KKK IK IKK RK II TK KIKI RR KK II IK 


File Name: qazcadsk 
File Type: physical 


Function: Database file where the client disk storage 
information is maintained. The data is obtained 
from the HOST MIB. 


ZCCIDX --> Client Index 
ZCCDEV --> Device Index 
ZCCACC --> Disk Access 
ZCCMED --> Disk Media 

ZCCRMV --> Disk Media Remove 
ZCCCAP --> Disk Capacity 


FF HH FH HF HF HF HH HF 


Wek End of Specifications OS Se Se 


UNIQUE 


R QZCADSKR 
ZCCIDX 12H 
ZCCDEV 9B 
ZCCACC 9B 
ZCCMED 9B 
ZCCRMV 9B 
ZCCCAP 9B 

K ZCCIDX 

K ZCCDEV 


QAZCAFS 


aK Start of specifications oe ee ee 


eo FF F FF FH FF F HF F F HF FH HF 


* 
* 
* 


End 


File Name: qazcafs 
File Type: physical 


Function: Database file where the client file system 


information is maintained. The data is obtained 
from the HOST MIB. 


ZCDIDX --> Client Index 
ZCDFS --> File System Index 
ZCDLMP --> Mount Point 
ZCDRMP --> Remote Mount 
ZCDTYP --> Type 

ZCDACC --> Access 

ZCDBOT --> Bootable 

ZCDSTG --> Storage Index 
ZCDFBK --> Full Backup 
ZCDPBK --> Partial Backup 


of Specifications RIKI K KICK KK I IK IK IKK IK KK IK II IKK IK I 
UNIQUE 
R QZCAFSR 


LMP 128A VARLEN (128) 
RMP 128A VARLEN (128) 


QAZCAMSC 


tek Start of specifications Co Se es ee 


FF be FH FF HH HHH HH HH HH H HH HF 


xxx End 
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File Name: qazcamsc 
File Type: physical 


Function: Database file where the basic client directory 


information is maintained 


ZCBIDX --> Client Index 
ZCBMEM --> Memory size 
ZCBUPT --> Up Time 

ZCBSTT --> System Status 
ZCBMBI --> Support MIBII 
ZCBMBH --> Support HOST MIB 
ZCBMBA --> Support APPN MIB 
ZCBMBX --> Support Extensions 
ZCBHDW --> Hardware Refresh 
ZCBSFW --> Software Refresh 
ZCBCON --> Contact 

ZCBLOC --> Location 

ZCBTYP --> Machine Type 
ZCBMDL --> Machine Model 
ZCBUSR --> User Profile 
ZCBOWN --> Owner 

ZCBPHN --> Owner Phone 
ZCBOFC --> Office 


Vv 


of Specifications HRT KI KK I IK IK IK KIKI KICK IK IKK I IK 


UNIQUE 
R QZCAMSCR 

ZCBIDX 12H 

ZCBMEM 9B 

ZCBUPT 9B 

ZCBSTT 9B 

ZCBMBI 9B 

ZCBMBH 9B 

ZCBMBA 9B 

ZCBMBX 9B 

ZCBHDW Z 

ZCBSFW Z 

ZCBCON 255A VARLEN (255) 
ZCBLOC 255A VARLEN (255) 
ZCBTYP 4A VARLEN(4) 
ZCBMDL 3A VARLEN (3) 
ZCBUSR 10A VARLEN(10) 
ZCBOWN 32A VARLEN (32) 
ZCBPHN 32A VARLEN (32) 
ZCBOFC 32A VARLEN (32) 

K ZCBIDX 


QAZCANET 


aK Start of specifications ee Se ee er 


File Name: qazcanet 
File Type: physical 


Function: Database file where the client network 
from the HOST MIB. 
ZCEIDX --> Client Index 


ZCEDEV --> Device Index 
ZCENIF --> Network IFIndex 


FF FF FF FH FH F 


wk End of Specifications OS 2 Se 


UNIQUE 
R QZCANETR 
ZCEIDX 12H 
ZCEDEV 9B 
ZCENIF 9B 
K ZCEIDX 
K ZCEDEV 


QAZCAPRC 


tek Start of specifications KKK KKK KKK KKK KKK KKK EKER ERE KER RR ER 


File Name: gqazcaprc 
File Type: physical 


Function: Database file where the client processor 
from the HOST MIB. 
ZCFIDX --> Client Index 
ZCFDEV --> Device Index 


ZCFLOD --> Processor Load 
ZCFFRM --> Processor Licensed Internal Code 


FF HF FH FF HH OF 


* 
* 
* 


UNIQUE 
R QZCAPRCR 
ZCFIDX 12H 
ZCFDEV 9B 
ZCFLOD 9B 
ZCFFRM 128A 
K ZCFIDX 
K ZCFDEV 


VARLEN (128) 


QAZCAPRT 


aK Start of specifications KKK KKK KKK KKK KKK KEK ERE KERR KERR RRR 


File Name: gqazcaprt 
File Type: physical 


OF 


information is maintained. The data is obtained 


information is maintained. The data is obtained 


End of Specifications KKK K AKA KK KR EKER KIKI KKK ERE KIER IER ARK 


Q 


KK 


et FF FF F HF F HF F HF HF F F 


* 
* 
* 


Q 


RK 


FF F FF F HF F FF F F 


* 
* 
* 


Function: Database file where the client printer 


information is maintained. The data is obtained 


from the HOST MIB. 


ZCGIDX --> Client Index 
ZCGDEV --> Device Index 
ZCGSTT --> Status 

ZCGERR --> Error State 


End of Specifications KKK KAKA KK KR EKER IKI KIRK EK EKER EKER ARK 
UNIQUE 

R QZCAPRTR 
ZCGIDX 12H 
ZCGDEV 9B 
ZCGSTT 9B 
ZCGERR 4H VARLEN (1) 

K ZCGIDX 

K ZCGDEV 


AZCAPTN 


Start of specifications KAKI RK IR KKK KIRK IK KI KKK IR KR RIK 


File Name: gqazcaptn 
File Type: physical 


Function: Database file where the client storage partition 
information is maintained. The data is obtained 


from the HOST MIB. 


ZCHIDX --> Client Index 
ZCHDEV --> Device Index 
ZCHPTN --> Partition Index 
ZCHSIZ --> Size 

ZCHFSX --> FS Index 

ZCHLBL --> Label 


ZCHID --> Id 
End of Specifications KKK KKK KKK KEKE KEK RK RK KERR ERK RE ER ERE 
UNIQUE 
R QZCAPTNR 
ZCHIDX 12H 
ZCHDEV 9B 
ZCHPTN 9B 
ZCHSIZ 9B 
ZCHFSX 9B 
ZCHLBL 128A VARLEN(128) 
ZCHID 128H VARLEN(128) 
K ZCHIDX 
K ZCHDEV 
K ZCHPTN 


AZCADRL 


Start of specifications KKK KKK KKK KKK KEK K EKA K AREER ARERR 


File Name: gqazcadrl 
File Type: logical 


Function: Database file where the basic client directory 


information is maintained 


ZCBIDX --> Client index 
ZCBCLT --> Client ID 

ZCBDSC --> Client Description 
ZCBCMN --> Community 

ZCBIPA --> IP Address 

ZCBCPN --> CP NetID 


End of Specifications ee ee ee eee ee ee ee od 
UNIQUE 

R QZCADRLR PFILE(QSYS/QAZCADIR) 
ZCBCLT 255A VARLEN 
ZCBIDX 12H 
ZCBDSC 255A VARLEN 
ZCBCMN 255A VARLEN 
ZCBIPA 15A VARLEN 
ZCBCPN 17A VARLEN 

K ZCBCLT 
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QAZCASFW 


xxe Start of specifications 


File Name: qazcasfw 
File Type: physical 
Function: 


ZCJSFW --> Software 
ZCJTYP --> Software 
ZCJSTT --> Software 
ZCJID --> Software 
ZCJVER --> Software 
ZCJOPT --> Software 
ZCJFTR --> Software 
ZCUMNF --> Software 
ZCJPTH --> Software 
ZCJDAT --> Software 
ZCJNAM --> Software 
ZCJSN --> Software 


FF HF FF H HF F HF HH H HF HF HF HF HF HK 


* 
* 
* 


End of Specifications 


R QZCASFWR 
ZCJIDX 12H 
ZCJSFW 9B 
ZCJTYP 9B 
ZCJSTT 9B 
ZCJID 128A 
ZCJVER 64A 
ZCJOPT 16A 
ZCJFTR 16A 
ZCUMNF 64A 
ZCJPTH 255A 
ZCJDAT Z 
ZCJNAM 64A 
ZCJSN 64A 

K ZCJIDX 

K ZCJSFW 


QAZCASFX 


xxx Start of specifications 


File Name: 


* 

* qazcasfx 
* File Type: 

* 

* 


physical 


Function: 


information is maintained. 
from the HOST MIB extensions. 


RII KA IKK I IK III I IO KI I IK III KI IK 


Database file where the client software 


The data is obtained 


ZCJIDX --> Client Index 


Index 

Type 

Status 

Id 

Version 
Option 
Feature 
Manufacture 
Path 

Date 

Name 
SerialNumber 


KAKI RIK KK I IK III KR IKK IK III KK IK IK 


UNIQUE 


VARLEN(7) 
VARLEN (6) 
VARLEN (4) 
VARLEN (4) 
VARLEN (32) 
VARLEN (128) 


VARLEN (32) 
VARLEN (32) 


RII I KA IO KI I IK III KI IORI I IK III I IO 


Database file where the Client software fix 


information is maintained. The data is obtained 
from the HOST MIB extensions. 


ZCKIDX --> Client Index 
ZCKSFW --> Software Index 
ZCKSFX --> Software Fix Index 
ZCKFIX --> Software Fix Id 


FF FF HF HF FH 


* 
* 
* 


End of Specifications KKK KA KARR KR KK ERIKA KIRK IER EKER EKER ARK 


UNIQUE 

R QZCASFXR 

ZCKIDX 12H 

ZCKSFW 9B 

ZCKSFX 9B 

ZCKFIX 16A VARLEN(7) 
K ZCKIDX 
K ZCKSFW 
K ZCKFIX 


QAZCASTG 


tek Start of specifications KKK KKK KK KK KKK KKK KKK ERE KER ERE RRR 


File Name: qazcastg 
File Type: physical 
Function: Database file where the client storage 


information is maintained. The data is obtained 


from the HOST MIB. 


ZCIIDX --> Client index 
ZCISTG --> Storage index 
ZCITYP --> Type 

ZCIDSC --> Description 

ZCIALU --> Allocation Units 
ZCISIZ --> Size 

ZCIUSD --> Used 

ZCIALF --> Allocation Failure 


FF He HF FF HF HH HF HF HF H HF 


* 
* 
* 


End of Specifications KKK K AKA KK KKK KER IEKI KAKA EKER EKER ER ARK 


UNIQUE 

R QZCASTGR 

ZCIIDX 12H 

ZCISTG 9B 

ZCITYP 9B 

ZCIDSC 128A VARLEN (128) 

ZCIALU 9B 

ZCISIZ 9B 

ZCIUSD 9B 

ZCIALF 9B 
K ZCIIDX 
K ZCISTG 
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Part 2. Using the SNMP Subagent DPI API 


© Copyright IBM Corp. 1997 


OS/400 Simple Network Management Protocol (SNMP) Support V4R1 


Chapter 5. Introduction to SNMP Distributed Protocol 


Interface 


The Simple Network Management Protocol 
(SNMP) agent distributed protocol interface (DPI) 
permits users to dynamically add, delete, or 
replace management variables in the local Man- 
agement Information Base (MIB) without requiring 
you to recompile the SNMP agent. 


This chapter describes the SNMP DPI routines 
that are supported by OS/400. This Application 
Programming Interface (API) is for the DPI suba- 
gent programmer. 


For additional information, you may also want to 
obtain a copy of RFC1592 (SNMP DPI 2.0 RFC). 


SNMP Agents and Subagents 


SNMP agents are responsible for answering 
SNMP requests from network management 
stations. Examples of management requests that 
are performed on the MIB objects are GET, 
GETNEXT, and SET. 


A subagent extends the set of MIB objects that 
are provided by the SNMP agent. With the suba- 
gent, you define MIB variables useful in your own 
environment and register them with the SNMP 
agent. 


When the agent receives a request for a MIB vari- 
able, it passes the request to the subagent. The 
subagent then returns a response to the agent. 
The agent creates an SNMP response packet and 
sends the response to the remote network man- 
agement station that initiated the request. The 
existence of the subagent is transparent to the 
network management station. 


DPI Agent Requests 
The SNMP agent can initiate several DPI 
requests: 


e get 
¢ getnext 
e set, commit, and undo 
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¢ unregister 
¢ close 


The SNMP subagent can initiate these DPI 
requests: 


* open, close 
¢ register 

* response 
e trap 


The SNMP subagent communicates with the 
SNMP agent using these functions: 


¢ connect, disconnect 
e receive, wait 
¢ send 


The GET, GETNEXT, and SET requests corre- 
spond to the SNMP requests that a network man- 
agement station can make. The subagent 
responds to a request with a response packet. 
The response packet can be created using the 
mkDPlresponse() library routine, which is part of 
the DPI API library. 


COMMIT, UNDO, UNREGISTER, and CLOSE 
requests are specific SNMP DPI requests. 


The subagent normally responds to a request with 
a RESPONSE packet. For the CLOSE and 
UNREGISTER requests, the subagent does not 
need to send a RESPONSE. 


SNMP DPI API Source Files 


The following source file is provided: 


The public SNMP DPI 2.0 API 
as provided to the DPI suba- 
gent programmer. The DPI 
subagent code must include 
this file. 


qtossapi.h 


This source file is available in source file H, 
member QTOSSAPI, in library QSYSINC. (If you 
cannot locate this file, contact your system support 
department. The QSYSINC library can be selec- 
tively installed at any time.) 
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Compiling, Linking, and Running 
a DPI API Application 


Programs using the SNMP subagent API must be 
written in the C language. Use ILE C/400 to 
compile the program with the Create C Module 
(CRTCMOD) CL command. After the *MOD 
object is created, specify 
BNDSVRPGM(QTOSSAPI) in the Create Program 
(CRTPGM) CL command. For additional informa- 


tion, see the /LE C/400 Programmer's Guide. and 
the /LE C/400 Programmer's Reference. 


Additional DPI Information 


For information on the SNMP APIs, see “Simple 
Network Management Protocol (SNMP) Subagent 
APIs” in the book System API Reference: 
UNIX-Type APIs. 
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The DPI API for OS/400 is the 2.0 level of the pro- 
tocol. This is designed to be highly compatible 
with SNMPv2 even if the SNMP Agent is 
SNMPv1. This compatibility allows future 
upgrades of a subagent implementation for use 
with a SNMPv2 Agent. Specifically: 


e Use only the SNMP Version 2 error codes 
even if there are definitions for the SNMP 
Version 1 error codes. 


¢ Implement the SET, COMMIT, UNDO pro- 
cessing as described in the sections that 
follow. 


e¢ For GET requests, use the SNMP Version 2 
approach and pass back noSuchlInstance 
value or noSuchObject value if such is the 
case. Continue to process all remaining 
varBinds. 


e For GETNEXT, use the SNMP Version 2 
approach and pass back endOfMibView value 
if such is the case. Continue to process all 
remaining varBinds. 


e When you are processing a request from the 
agent (GET, GETNEXT, SET, COMMIT, or 
UNDO), you are supposed to respond within 
the time-out period. You can specify the 
time-out period in the OPEN and REGISTER 
packets. 


If you fail to respond within that time-out 
period, the agent will most probably close your 
DPI connection and then discard your 
RESPONSE packet if it comes in later. If you 
can detect that the response is not going to 
be received in the time period, then you might 
decide to stop the request and return an 
SNMP_ERROR_genErr in the RESPONSE. 


e You may want to issue an SNMP DPI 
ARE_YOU_THERE request periodically to 
ensure that the agent is still connected and 
still knows about you. 


¢ Generally, SNMP agents and managers use 
the printable ASCII character set to represent 
DisplayString values. For additional informa- 
tion on the mkDPlopen() API, see “Simple 
Network Management Protocol (SNMP) Suba- 
gent APIs” in the book System API Reference: 
UNIX-Type APIs. 
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e If you receive an error RESPONSE on the 
OPEN packet, you will also receive a DPI 
CLOSE packet with an 
SNMP_CLOSE_openError code. In this situ- 
ation, the agent closes the connection. 


e Please realize that DisplayString is only a 
textual convention. In the SNMP PDU (SNMP 
packet), the type is just an OCTET_STRING. 


When the type is OCTET_STRING, it is not 
clear if this is a DisplayString or any arbitrary 
data. This means that the agent can only 
know about an object being a DisplayString if 
the object is included in some sort of a com- 
piled MIB. If it is, the agent will use 
SNMP_TYPE_DisplayString in the type field of 
the varBind in a DPI SET packet. When you 
send a DisplayString in a RESPONSE packet, 
the agent will handle it as such. 


Related Information 


RFC1440 through RFC1452 are the SNMP 
Version 2 RFCs. 


GET Processing 


The DPI GET packet holds one or more varBinds 
that the subagent has taken responsibility for. 


If the subagent encounters an error while pro- 
cessing the request, it creates a DPI RESPONSE 
packet with an appropriate error indication in the 
error_code field. The subagent then sets the 
error_index to the position of the varBind at which 
the error occurs. The first varBind is index 1, the 
second varBind is index 2, and so on. No OID, 
type, length, or value information needs to be pro- 
vided in the packet. This is because, by definition, 
the varBind information is the same as in the 
request to which this is a response and the agent 
still has that information. 


If there are no errors, the subagent creates a DPI 
RESPONSE packet in which the error_code is set 
to SNMP_ERROR_noError (zero) and error_index 
is set to zero. The packet must also include the 
OID, type, length, and value of each varBind 
requested. 


6-1 


When you get a request for a non-existing object 
or a non-existing instance of an object, you must 
return a NULL value with a type of 
SNMP_TYPE_noSuchObject or 
SNMP_TYPE_noSuchInstance respectively. 
These two values are not considered errors, so 
the error_code and error_index should be zero. 


The DP] RESPONSE packet is then sent back to 
the agent. 


SET Processing 


A DPI SET packet contains the OID, type, length, 
and value of each varBind requested, plus the 
value type, value length, and value to be set. 


If the subagent encounters an error while pro- 
cessing the request, it creates a DPI RESPONSE 
packet with an appropriate error indication in the 
error_code field and an error_index listing the 
position of the varBind at which the error occurs. 
The first varBind is index 1, the second varBind is 
index 2, and so on. No OID, type, length, or value 
information needs to provided in the packet. This 
is because, by definition, the varBind information 
is the same as in the request to which this is a 
response and the agent still has that information. 


If there are no errors, the subagent creates a DPI 
RESPONSE packet in which the error_code is set 
to SNMP_ERROR_noError (zero) and error_index 
is set to zero. No OID, type, length, or value 
information is needed because the RESPONSE to 
a SET should contain exactly the same varBind 
data as the data present in the request. The 
agent can use the values it already has. 


This suggests that the agent must keep state 
information. This is the case. The subagent 
keeps state information to make it able to pass the 
data with a DPI COMMIT or DPI UNDO packet. 
Because there are no errors, the subagent must 
have allocated the required resources and pre- 
pared itself for the SET. It does not yet carry out 
the set. That will be done at COMMIT time. 


The subagent sends a DPI RESPONSE packet, 
indicating success or failure for the preparation 
phase, back to the agent. The agent will issue a 
SET request for all other varBinds in the same ori- 


ginal SNMP request it received. This may be to 
the same subagent or to one or more different 
subagents. 


Once all SET requests have returned a no error 
condition, the agent starts sending DP! COMMIT 
packets to the subagents. If any SET request 
returns an error, the agent sends DP! UNDO 
packets to those subagents that indicated suc- 
cessful processing of the SET preparation phase. 


When the subagent receives the DPI COMMIT 
packet, all the varBind information will again be 
available in the packet. The subagent can now 
carry out the SET request. 


If the subagent encounters an error while pro- 
cessing the COMMIT request, it creates a DPI 
RESPONSE packet with value 
SNMP_ERROR_commitFailed in the error_code 
field. An error_index that lists at which varBind 
the error occurs is also created. The first varBind 
is index 1, and so on. No OID, type, length, or 
value information is needed. The fact that a 
commitFailed error exists does not mean that this 
error should be returned easily. A subagent 
should do all that is possible to make a COMMIT 
succeed. 


If there are no errors and the SET and COMMIT 
have been carried out with success, the subagent 
creates a DP! RESPONSE packet in which the 
error_code is set to SNMP_ERROR_noError 
(zero) and error_index is set to zero. No OID, 
type, length, or value information is needed. 


So far we have discussed a successful SET and 
COMMIT sequence. However, after a successful 
SET, the subagent may receive a DPI UNDO 
packet. The subagent must now undo any prepa- 
rations it made during the SET processing, such 
as free allocated memory. 


Even after a COMMIT, a subagent may still 
receive a DPI UNDO packet. This will occur if 
some other subagent could not complete a 
COMMIT request. Because of the SNMP require- 
ment that all varBinds in a single SNMP SET 
request must be changed as if all changes were 
simultaneous, all committed changes must be 
undone if any of the COMMIT requests fail. In 
this case the subagent must try to undo the com- 
mitted SET operation. 
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If the subagent encounters an error while pro- 
cessing the UNDO request, it creates a DPI 
RESPONSE packet with value 
SNMP_ERROR_undoFailed in the error_code 
field. An error_index that lists at which varBind 
the error occurs is also created. The first varBind 
is index 1, and so on. No OID, type, length, or 
value information is needed. The fact that an 
undoFailed error exists does not mean that this 
error should be returned easily. A subagent 
should do all that is possible to make an UNDO 
succeed. 


If there are no errors and the UNDO has been 
successful, the subagent creates a DPI 
RESPONSE packet in which the error_code is set 
to SNMP_ERROR_noError (zero) and error_index 
is set to zero. No OID, type, length, or value 
information is needed. 


GETNEXT Processing 


The DPI GETNEXT packet contains the objects on 
which the GETNEXT operation must be per- 
formed. For this operation, the subagent is to 
return the OID, type, length, and value of the next 
variable it supports whose (ASN.1) OID 
lexicographically follows the one passed in the 
group ID (subtree) and instance ID. 


In this case, the instance ID may not be present 
(NULL) in the incoming DPI packet implying that 
the NEXT object must be the first instance of the 
first object in the subtree that was registered. 


It is important to realize that a given subagent 
may support several discontiguous sections of the 
MIB tree. In that situation, it would be incorrect to 
jump from one section to another. This problem is 
correctly handled by examining the group ID in the 
DPI packet. This group ID represents the reason 
why the subagent is being called. It holds the 
prefix of the tree that the subagent had indicated it 
supported (registered). 


If the next variable supported by the subagent 
does not begin with that prefix, the subagent must 
return the same object instance as in the request. 
For example, the group ID and instance ID with a 
value of SNMP_TYPE_endOfMibView (implied 
NULL value). This endOfMibView is not consid- 
ered an error, so the error_code and error_index 


should be zero. If required, the SNMP agent will 
call the subagent again, but pass it a different 
group ID (prefix). This is illustrated in the dis- 
cussion below. 


Assume that there are two subagents. The first 
subagent registers two distinct sections of the 
tree: AandC. In reality, the subagent supports 
variables A.1 and A.2, but it correctly registers the 
minimal prefix required to uniquely identify the var- 
iable class it supports. 


The second subagent registers section B, which 
appears between the two sections that are regis- 
tered by the first agent. 


If a management station begins browsing the MIB, 
starting from A, the following sequence of queries 
of the form get-next(group ID,instance ID) would 
be performed: 


Subagent 1 gets called: 


get-next(A,none) = A.1 
get-next(A,1) = A.2 
get-next (A,2) = endOfMibView 


Subagent 2 is then called: 
get-next(B,none) = B.1 
get-next(B,1) = endOfMibView 


Subagent 1 gets called again: 
get-next(C,none) = C.1 


OPEN Request 


After a successful connection is made, a DPI sub- 
agent must open a connection with the agent. To 
do so, the subagent must send a DPI OPEN 
packet in which these parameters must be speci- 
fied: 


e¢ The maximum time-out value in seconds. The 
agent is requested to wait this long for a 
response to any request for an object being 
handled by this subagent. 


The agent may have an absolute maximum 
time-out value which will be used if the suba- 
gent asks for too large a time-out value. A 
value of zero can be used to indicate that the 
agent's own default time-out value should be 
used. A subagent is advised to use a reason- 
ably short interval of a few seconds. If a spe- 
cific subtree needs a (much) longer time, a 
specific REGISTER can be done for that 
subtree with a longer time-out value. 
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e The maximum number of varBinds that the 
subagent is prepared to handle per DPI 
packet. Specifying 1 would result in DPI 
Version 1 behavior of one varBind per DPI 
packet that the agent sends to the subagent. 
A value of zero means the agent will try to 
combine up to as many varBinds as are 
present in the SNMP packet that belongs to 
the same subtree. 


e The character set you want to use. By 
default, a0 value. This is the native character 
set of the machine platform where the agent 
runs. Since the subagent and agent normally 
run on the same system or platform, you want 
to use the native character set, which on 
many platforms is ASCII. 


If your platform is EBCDIC based, using the 
native character set of EBCDIC makes it easy 
to recognize the string representations of the 
fields, such as the group ID and instance ID. 
At the same time, the agent will translate the 
value from printable ASCII to EBCDIC and 
vice versa for objects that it knows from a 
compiled MIB to have a textual convention of 
DisplayString. This fact cannot be determined 
from the SNMP PDU encoding because in the 
PDU the object is only known to be an 
OCTET_STRING. 


¢ The subagent ID. This an ASN.1 Object Iden- 
tifier that uniquely identifies the subagent. 
This OID is represented as a null-terminated 
string using the selected character set. 


For example: 1.3.5.1.2.3.4.5 


¢ The subagent description. This is a 
DisplayString that describes the subagent. 
This is a character string that uses the 
selected character set. 


For example: DPI sample subagent Version 
2.0 


Once a subagent has sent a DP! OPEN packet to 
an agent, it should expect a DP! RESPONSE 
packet that informs the subagent about the result 
of the request. The packet ID of the RESPONSE 
packet should be the same as that of the OPEN 
request to which the RESPONSE packet is the 
response. 


If you receive an error RESPONSE on the OPEN 
packet, you will also receive a DPI CLOSE packet 
with an SNMP_CLOSE_openError code. In this 
situation, the agent closes the connection. 


If the OPEN is accepted, the next step is to REG- 
ISTER one or more MIB subtrees. 


This sequence is depicted in Figure 6-1. 


connectSNMP() 
v 
mkDPIopen() 
v 
sendDPIpacket() 
v 
waitDPIpacket() 


v 
pDPIpacket() 


v 
// check packet return code 


Figure 6-1. Subagent initiation DPI API call sequence. 


CLOSE Request 


When a subagent is finished and wants to end 
processing, it should first UNREGISTER its sub- 
trees and then close the connection with the 
agent. To do so, the subagent must send a DPI 
CLOSE packet, which specifies a reason for the 
closing. You should not expect a response to the 
CLOSE request. 


A subagent should also be prepared to handle an 
incoming DPI CLOSE packet from the agent. In 
this case, the packet will contain a reason code 
for the CLOSE request. A subagent does not 
have to send a response to a CLOSE request. 
The agent just assumes that the subagent will 
handle it appropriately. The close takes place 
regardless of what the subagent does with it. 


This sequence is depicted in Figure 6-2 on 
page 6-5. 
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mkDPIclose() 


sendDPIpacket() 


disconnectSNMP () 


Figure 6-2. Ending a subagent. 


REGISTER Request 


Before a subagent will receive any requests for 
MIB variables, it must first register the variables or 
subtree it supports with the SNMP agent. The 
subagent must specify a number of parameters in 
the REGISTER request: 


e The subtree to be registered. This is a null- 
terminated string in the selected character set. 
The subtree must have a trailing dot. 


For example: 1.3.6.1.2.3.4.5. 


e The requested priority for the registration. 
The values are: 


-1 Request for the best available pri- 
ority. 
0 Request for the next best available 


priority than the highest (best) pri- 
ority currently registered for this 
subtree. 


NNN Any other positive value requests 
that specific priority if available or 
the next worse priority that is avail- 
able. 


e The maximum time-out value in seconds. The 
agent is requested to wait this long for a 
response to any request for an object in this 
subtree. The agent may have an absolute 
maximum time-out value which will be used if 
the subagents ask for too large a time-out 
value. A value of zero can be used to indi- 
cate that the DP! OPEN value should be used 
for time-out. 


¢ A specification if the subagent wants to do 
view selection. If it does, the community 
name from SNMP Version 1 packets will be 
passed in the DPI GET, GETNEXT, and SET 
packets. 


¢ A specification if the subagent wants to 
receive GETBULK packets or if it just prefers 


that the agent converts a GETBULK into mul- 
tiple GETNEXT requests. 


Once a subagent has sent a DPI REGISTER 
packet to the agent, it should expect a DPI 
RESPONSE packet that informs the subagent 
about the result of the request. The packet ID of 
the RESPONSE packet should be the same as 
that of the REGISTER packet to which the 
RESPONSE packet is the response. 


If the response is successful, the error_index field 
in the RESPONSE packet contains the priority that 
the agent assigned to the subtree registration. 


This sequence is depicted in Figure 6-3. 


mkDPIregistr() <——————_—__ 
v 

sendDPIpacket() 
v 

waitDPIpacket() 
v 

pDPIpacket() 


v 
// check packet return code 


Figure 6-3. Subagent registration DPI API call 
sequence. (multiple subtrees can be registered.) 


UNREGISTER Request 


A subagent may unregister a previously registered 
subtree. The subagent must specify a few param- 
eters in the UNREGISTER request: 


e The subtree to be unregistered. This is a null- 
terminated string in the selected character set. 
The subtree must have a trailing dot. 


For example: 1.3.6.1.2.3.4.5. 
e The reason for the unregister. 
Once a subagent has sent a DP! UNREGISTER 
packet to the agent, it should expect a DPI 
RESPONSE packet that informs the subagent 


about the result of the request. The packet ID of 
the RESPONSE packet should be the same as 
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that of the REGISTER packet to which the 
RESPONSE packet is the response. 


A subagent should also be prepared to handle 
incoming DP! UNREGISTER packets from the 
agent. In this situation, the DPI packet will contain 
a reason code for the UNREGISTER. A subagent 
does not have to send a response to an UNREG- 
ISTER request. The agent just assumes that the 
subagent will handle it appropriately. The registra- 
tion is removed regardless of what the subagent 
returns. 


TRAP Request 


A subagent can request the SNMP agent to gen- 
erate a trap. The subagent must provide the 
desired values for the generic and specific param- 
eters of the trap. The subagent may optionally 
provide a set of one or more OID, type, length, or 
value parameters that will be included in the trap 
packet. 


It may optionally specify an Enterprise ID (Object 
Identifier) for the trap to be generated. If a NULL 
value is specified for the Enterprise ID, the agent 
will use the subagent Identifier from the DPI 
OPEN packet as the Enterprise ID to be sent with 
the trap. The trap is sent by the SNMP agent to 
the set of trap manager's that are currently config- 
ured for the SNMP agent using the CHGSNMPA 
CL command. In other words, the subagent does 
not determine where the trap is sent. 


This sequence is depicted in Figure 6-4. 


mkDPIset() <— 


v 
mkDPI trap () 


v 
sendDPIpacket() 


Figure 6-4. Subagent initiated trap. 


ARE_YOU_THERE Request 


A subagent can send an ARE_YOU_THERE 
packet to the agent. This may be useful to verify 
that the SNMP agent is still active and the con- 
nection is working. 


If the connection is in a healthy state, the agent 
responds with a RESPONSE packet with 
SNMP_ERROR_DPI_noError. If the connection is 
not in a healthy state, the agent may respond with 
a RESPONSE packet with an error indication. 
But, the agent might not react at all. In this situ- 
ation, you would time-out while waiting for a 
response. 


Communicating with the SNMP 
Agent 


An SNMP subagent communicates with the SNMP 
agent on the same AS/400 system using these 
APIs: 

connectSNMP() 

disconnectSNMP () 

sendDPI packet () 

waitDPIpacket () 

receiveDPIpacket() 


The technical details about these APIs (parame- 
ters, return codes, and so on) can be found in 
“Simple Network Management Protocol (SNMP) 
Subagent APIs” the book System API Reference: 
UNIX-Type APIs. This section provides some 
additional information on how to use these APIs. 


The connectSNMP\() call is the very first subagent 
API that is used. The call establishes a logical 
connection with the SNMP agent (running on the 
same AS/400 as the subagent) and prepares the 
agent for the next logical subagent event. The 
next event is to perform a DPI open function (see 
mkDPlopen() section). The parameters to 
connectSNMP() specify a data queue that the sub- 
agent wants the SNMP agent to use when 
sending work to the subagent. This data queue 
name is used by the agent (For example, in the 
SNMP subagent MIB. The SNMP subagent MIB 
is described in “SNMP Subagent MIB” on 

page A-6.) as part of the identity for a subagent. 
Hence, only a single subagent may use a partic- 
ular data queue at any one time. Note that this 
API does not create the data queue for the suba- 
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gent — the data queue should have already been 
created when this call is made. 


The disconnectSNMP() call is the logical opposite 
of the connect function and is the very last suba- 
gent API that is used. The call ends or closes the 
logical connection between the SNMP agent and 
the subagent. All DPI subagent functions are pre- 
formed within the logical bracket formed by a 
connect and disconnect. 


At any given time, a subagent may have: 
¢ Oor1 connections with the SNMP agent 
¢ Oor1 opens with the SNMP agent 
¢ OQorn registrations (no logical upper bound) 


Zero opens is not a useful normal condition for a 
subagent. This would occur briefly only between 
a connectSNMP() call and the sending of a DPI 
open packet. Zero registrations might be useful 
for a subagent that only sends traps and does not 
implement any MIB groups. More than a single 
subtree registration may be useful for a variety of 
reasons: 


1. Perhaps separate MIBs are being imple- 
mented by separate people, but it is decided 
to have these MIB implementations all run 
within a single job, which will perform the sub- 
agent API functions on behalf of the MIB 
implementers 


2. Perhaps a few OIDs within a MIB are known 
to be relatively large overhead, compared to 
the rest of the subtree, for a DPI request type 
(for example, set). There may be perfor- 
mance benefits to registering these OIDs sep- 
arately than the rest of the subtree, with a 
different time-out value. 


The sendDPlpacket() API does just this — for any 
type of DPI packet a subagent wants to send, this 
routine is used to send it. 


The waitDPlpacket() and receiveDPlpacket() are 
alternative ways of getting responses and work 
from the SNMP agent. Generally, a given suba- 
gent implementation chooses one or the other, 
and does not need both. But both can be used in 
the same subagent, if desired. The difference 
between the two APIs is that waitDPlpacket() 
completely handles the subagent's data queue, 
logically doing these steps: 


1. Check data queue for an incoming message 


2. When data queue has a message, receive the 
message 


3. Check the message, if not from SNMP agent, 
return it to caller 


4. If the message is from the SNMP agent, copy 
DPI packet to subagent buffer 


In contrast, receiveDPlpacket() does only the last 
step. In which case, the subagent implementation 
must perform the first three. (Note that the DPI 
packet itself is not the message that is placed on 
the subagent's data queue. See the 
sa_dataq_msg structure in qtossapi.h for the 
format of the data queue message from the SNMP 
agent. The purpose of the data queue message, 
is to signal the subagent that a DPI packet is 
pending.) 


Waiting for Work from the SNMP 
Agent 


The main purpose for which an SNMP subagent is 
developed is to provide additional MIB groups to 
SNMP manager applications. Therefore, an 
SNMP subagent spends most of its time waiting 
for (and processing) requests that an SNMP 
manager has sent to the local SNMP agent. 


Figure 6-5 on page 6-8 shows the structure for 


the core processing loop of a subagent implemen- 
tation. 
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v 
waitDPIpacket() < 


v 
pDPIpacket() 
t+————+ // other 


v 
// MIB implementation <— 


v 
mkDPIset () 


v 
mkDPIresponse() 


v 
sendDPI packet () 


Figure 6-5. Normal processing loop for a subagent. 


The waitDPlpacket() is at the top of the loop. 
When a request arrives from the SNMP agent, this 
API will receive it, verify that it is from the SNMP 
agent, and then return it to the caller. The DPI 
packet is then parsed by using the pDPlpacket() 
routine so that the packet contents are available. 


A key decision point occurs after a successful 
parse. The DPI packet may be a GET, 


GETNEXT, or SET, in which case the path to the 
MIB implementation is taken. If it is some other 
DPI packet (for example, unregister), the subagent 
will take some other appropriate action. 


The MIB implementation is the heart of a suba- 
gent and generally comprises well over one half of 
the total subagent implementation size. (Of 
course, it can go much higher if the MIB being 
implemented is very large.) The MIB code per- 
forms the requested operation (GET, GETNEXT, 
SET, COMMIT OR UNDO) on an OID, and a 
resulting varBind is built using the mkDPlset() 
routine. 


If the incoming DPI packet had multiple varBinds, 
it can be handled as the loop suggests; by going 
back into the MIB implementation for the next 
OID, and adding that result to the varBind list 
using mkDPIset(). 


When all the varBinds have been processed, the 
list of varBinds is used to build a response DPI 
packet by calling mkDPlresponse(). 


Lastly, the DPI response is sent back to the 
waiting SNMP agent by calling sendDPlpacket(). 
Then the subagent calls waitDPlpacket() again, 
with an appropriate time-out, to again another 
cycle of the normal processing loop. 
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Appendix A. OS/400 SNMP Agent Set Processing and 


Supported SNMP MIBs 


This appendix lists and describes the following 
MIBs that are related to SNMP: 


Standard RFC MIBs 


e MIB II (RFC1213) 

e Ethernet-like (RFC1398) 
e¢ FDDI (RFC1285) 

e Frame Relay (RFC1315) 
¢ Token Ring (RFC1231) 


IBM enterprise MIBs 


APPN MIB 

Client management MIB 
NetView for AIX subagent MIB 
DPI 2.0 (RFC1592) 

e¢ SNMP subagent MIB 


For more detailed information on these and other 
MIB groups, please refer to the concise MIB 
description. 


MIBs are distributed through the following mech- 
anisms: 


e If you have Internet access with FTP capa- 
bility, MIB modules can be obtained from the 
NetView Association MIB server at 
netview.cary.ibm.com. 

e IBM enterprise MIB modules supported by 
OS/400 are shipped with OS/400. Each MIB 
module is contained in a member of physical 
file QANMMIB in library QSYS. The physical 
file member name for each MIB module is 
listed as the MIB module name in the section 
that describes each enterprise MIB in this 
appendix. 

e If you have Internet access with FTP capa- 
bility, MIB modules for vendor MIBs registered 
under the enterprises subtree (including IBM 
MIBs) can be obtained by anonymous FTP 
from the Internet Assigned Numbers Authority 
(IANA) anonymous FTP server at 
venera.isi.edu. 

e As a last resort, MIB distribution can be initi- 
ated through the Internet address: 
as400_ sysman@vnet.ibm.com 
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OS/400 SNMP Agent Set 
Processing 


RFC 1157 requires that each set request variable 
assignment be effected as if simultaneously set 
with respect to all other assignments specified in 
the same message. This means that a set 
request with multiple instance |D/value pairs 
should be processed in an all-or-none fashion. 
That is, either all the new values of the variables 
are assigned without error, or else none of the 
values of the variables in the request are 
changed. This requirement is also known as 
atomic commit with rollback. 


For the MIB objects that are supported, the 
OS/400 SNMP agent checks the specified values 
for the MIB variables in the set request. If a spec- 
ified value does not meet the check requirements, 
the set request is rejected. The actual implemen- 
tation for the set request is technically a best 
effort, not a true atomic commit and rollback. 


During the set process when the agent is actually 
changing MIB object values, if a failure occurs, the 
original values of the MIB objects already set are 
not restored. 


Standard RFC MIBs 
MIB-II 


Overview: MIB-II describes those objects that 
are implemented by managed nodes that run the 
Internet suite of protocols. 


RFC: RFC 1213 


RFC noted exceptions: The egp group is 
not supported. The set operation is not supported 
for the following MIB object, which is defined as 
having read-write access. 


ifAdminStatus 


Note that ifAdminStatus tracks the desired state of 
a network interface as set with an OS/400 


command (for example, NETSTAT). Therefore, 
the get operation can still be used on 
ifAdminStatus and ifOperStatus to determine if 
there is a problem with an interface. 


The set operation is accepted for the following 
MIB objects, which are defined as having read- 
write access. However, the values will not change 
as a result of the set operation. This behavior 
allows an SNMP manager to successfully perform 
a set operation on an entire row of a table. A 
subsequent get operation will show which values 
have actually changed. 


¢ ipRoutelflndex 
¢ ipRouteMetric1 
¢ ipRouteMetric2 
¢ ipRouteMetric3 
e ipRouteMetric4 
e ipRouteAge 

e ipRouteMetric5 


For some MIB objects, the set operation is not 
supported for all values that are defined as being 
valid. These MIB objects are listed here, along 
with the values to which they can be set. 


ipRouteType invalid(2), indirect(4) 
ipNetToMediaType _ invalid(2), static(4) 
tcpConnState deleteTCB(12) 


In order to set the value of atNetAddress, its 
syntax must be encoded as OCTET STRING, 
rather than NetworkAddress. Note that it is never 
necessary to set the value of atNetAddress 
directly. This is because a row can be added to 
or deleted from the atTable by setting the value of 
only atPhysAddress. 


The result of changing the value of a MIB object 
that is an index to an instance of that MIB object 
is undefined. For example, the result of the oper- 
ation set ipRouteDest.9.130.38.28=9.130.38.29 
is undefined. 


When adding a row to a table by setting the value 
of a MIB object, default values are assigned to the 
other objects in the row. 


e indexes: The value of a MIB object which is 
an index to an instance of that MIB object 
need not be set explicitly. For example, the 
operation set 
j pRouteNextHop.9.130.38.28=9.130.25.250 
will implicitly create the MIB object instance 


ipRouteDest.9.130.38.28, with the value 
9.130.38.28. 


e atPhysAddress: There is no default value for 
this MIB object. The value of this MIB object 
must be set in order to create a new row in 
the atTable. 


e jpRouteNextHop There is no default value for 
this MIB object. The value of this MIB object 
must be set in order to create a new row in 
the ipRouteTable. 


e jpRouteType: indirect(4) 


e jpRouteMask: Corresponds to the network 
class. For example, the mask of a class-A 
network will default to 255.0.0.0. 


¢ jpNetToMediaPhysAddress: There is no 
default value for this MIB object. The value of 
this MIB object must be set in order to create 
a new row in the ipNetToMediaTable. 


e jipNetToMediaType: static(4) 


MIB Subtree Description: Management 
information base for network management of 
TCP/IP-based internets. 


MIB Subtree Object Identifier: mib-2 ::= { 
mgmt (1) } 


Prerequisite MIB Modules: RFC1155, 
RFC1212 


Ethernet-like Interface MIB 


Overview: Ethernet-like Interface MIB defines 
objects for managing ethernet-like object interface 
types. 


RFC: RFC1398 


RFC noted exception: The dot3CollTable 
is not supported. 


MIB Subtree Description: Ethernet-like 
MIB. 


MIB Subtree Object Identifier: dot3 ::= { 


transmission 7 } 
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Prerequisite MIB Modules: RFC1155, 
RFC1213, RFC1212 


FDDI MIB 


Overview: FDDI MIB defines objects for man- 
aging devices which implement the FDDI. 


RFC: RFC1285 

RFC noted exceptions: The Attachment 
group is not supported. The set operation is not 
supported for this MIB. 


MIB Subtree Description: FDDI! MIB. 


MIB Subtree Object Identifier: fddi ::= { 


transmission 15 } 


Prerequisite MIB Modules: RFC1155, 
RFC1213, RFC1212 


Frame Relay MIB 


Overview: Frame Relay objects for managing 
Frame Relay. 


RFC: RFC1315 


RFC noted exception: The set operation is 
supported for only frTrapState. 


MIB Subtree Description: Frame Relay 
MIB. 


MIB Subtree Object Identifier: frame- 
relay ::= { transmission 32 } 


Prerequisite MIB Modules: RFC1155, 
RFC1213, RFC1212, RFC1215 


IEEE 802.5 Token Ring MIB 


Overview: IEEE 802.5 Token Ring MIB 
defines managed objects used for managing sub- 
networks which use the IEEE 802.5 Token Ring 
technology described in 802.5 Token Ring Access 
Method and Physical Layer Specifications, IEEE 
Standard 802.5-1989. 


RFC: RFC1231 


RFC noted exception: The dot5TimerTable 
and the SET operation are not supported for this 
MIB. 


MIB Subtree Description: Token Ring MIB 


MIB Subtree Object Identifier: dot5 ::= { 


transmission 9 } 


Prerequisite MIB Modules: RFC1155, 
RFC1212 


IBM Enterprise MIBs 


Advanced Peer-To-Peer 
Networking (APPN) MIB 


Overview: The APPN Node Group provides 
global information about the APPN node, which is 
either a network node or an end node. 


The APPN Topology Group represents the entire 
APPN network topology including network nodes, 
virtual nodes, and all transmission groups (TGs) 
that are associated with these nodes. 


The APPN Local Topology Group describes the 
local topology. This MIB group defines the 
required objects for retrieval of information about 
this node and the objects that represent the local 
topology about end nodes. 


The APPN port table provides information on 
APPN ports and allows their state to be changed 
from an SNMP manager using SNMP SET on the 
port state object. (On the AS/400, APPN ports 
are APPN-capable lines.) 


The APPN link station table provides information 
on APPN link stations and allows their state to be 
changed from an SNMP manager using SNMP 
SET on the link station state object. (On the 
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AS/400, APPN link stations are APPC controllers 
that are attached to APPN-capable lines.) 


RFC: Informational RFC 1593 


RFC noted exceptions: Some groups of 


RFC 1593 are implemented with some extensions. 
Refer to the concise MIB description (MIB module) 


for details. 


MIB Subtree Description: SNA APPN MIB 


MIB Subtree Object Identifier: iobmappn 
i= { internet(1) private(4) enterprises(1) ibm(2) 
prod(6) ibm6611(2) 13 } 


MIB Module Name: |IBMAPPN 


The ASN.1 for this MIB is available in member 
IBMAPPN in file QSYS/QANMMIB. 


Prerequisite MIB Modules: RFC1155, 
RFC1212 


APPN MIB object groups that sup- 


ported: Groups that are supported under the 
iobmappnNode subtree: 


ibmappnGenerallnfoAndCaps 
ibmappnNnUniquelnfoAndCaps 
ibmappnEnUniqueCaps 
ibmappnSnmpinformation 


Groups that are supported under the ibmappnNn 
subtree: 


iomappnNnTopo (only 4 objects are sup- 
ported): 


iomappnNnTopoMaxNodes 
ibmappnNnTopoCurNumNodes 
iomappnNnTopoNodePurges 
iomappnNnTopoTgPurges 


iomappnNnTopology - tables for APPN 
network topology: 


iomappnNnTopologyTable 
iomappnNnTg Topology Table 
ibmappnNnTopologyFRT able 
iomappnNnTgTopologyFRT able 


Groups that are supported under the 
iomappnLocalTopology subtree: 


ibmappnLocalThisNode 


ibmappnLocalGeneral 
ibmappnLocalNnSpecific 
iomappnLocalTg - table of local trans- 
mission groups (TGs) 
iobmappnLocalEnTopology 


ibmappnLocalEnTable - table of adjacent end 
nodes 


ibmappnLocalEnTgTable - table of adjacent 
end node TGs 


The following objects are supported from the 
APPN port table: 


ibmappnNodePortName 
ibmappnNodePortState 
ibmappnNodePortDicType 
iobmappnNodePortPortType 
ibmappnNodePortLsRole 
ibmappnNodePortMaxRcvBtuSize 


The list of supported link station table objects 
follows. Any AS/400-specific considerations 
regarding the objects are listed in parenthesis 
after each object name. 


iomappnNodeLsName 
iobmappnNodeLsPortName 
iomappnNodeLsDicType 
ibmappnNodeLsDynamic (controller value for 
control owner) 

ibmappnNodeLsState 
ibmappnNodeLsCpName 
iomappnNodeLsTgNum 
iomappnNodeLsLimResource (controller value 
for switched disconnect) 
iobmappnNodeLsBlockNum 
ibmappnNodeLsidNum 
ibmappnNodeLsCpCpSession 
ibmappnNodeLsEffCap (0 implies *MAX, 1 
implies *MIN) 

ibmappnNodeLsConnCost 
ibmappnNodeLsByteCost 
ibmappnNodeLsSecurity 
iobmappnNodeLsDelay 

iomappnNodeLsUsr1 

iomappnNodeLsUsr2 

iomappnNodeLsUsr3 
ibmappnNodeLsHprSup: yes(1) iff APPN HPR 
capable is *YES 
ibmappnNodeLsErrRecoSup 
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Client Management MIB 


Overview: The Client System Group provides 
global information about the client, connectivity, 
and capabilities. 


The Client Hardware Group provides information 
that is related to storage, devices, file systems, 
and printers. 


The Client Software Group provides information 
that is related to installed software and fixes. 


RFC: None 
RFC noted exception: None 


MIB Subtree Description: Client Manage- 
ment 


MIB Subtree Object Identifier: 
clientMgmtSubAgent ::= { internet(1) private(4) 
enterprise(1) ibm(2) ibmprod(6) 50 } 


MIB Module Name: IBMCLTM 


The ASN.1 for this MIB is available in member 
IBMCLTM in file QSYS/QANMMIB. 


Prerequisite MIB Modules: RFC1155, 
RFC1212 


NetView for AIX Subagent MIB 


Overview: One MIB object in this MIB is sup- 
ported. The object provides the average per- 
centage of load (processor utilization) during the 
elapsed time. Each retrieval of this value is calcu- 
lated in the same manner as the value that is dis- 
played by the DSPSYSACT command when the 
restart function key is used. 


RFC: None 
RFC noted exception: None 


MIB Subtree Description: NetView for AIx 
subagent ComputerSystem group 
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MIB Subtree Object Identifier: 
nv6saComputerSystem ::= { internet(1) private(4) 
enterprises(1) ibm(2) prod(6) 
netView6000SubAgeni(4) 5 } 


MIB Module Name: IBMNV6SA 


The ASN.1 for this MIB is available in member 
IBMNVESA in file QSYS/QANMMIB. 


Prerequisite MIB Modules: RFC1155, 
RFC1212 


Note: A NetView for AIX application provides 
support for this data. 


NetView for AIX subagent MIB object 
supported 


nv6saComputerSystemLoad OBJECT-TYPE 


SYNTAX Gauge 

ACCESS read-only 

STATUS mandatory 
DESCRIPTION 

The CPU load as a percentage. For 
example, 25% is 2500. 

= { nv6saComputerSystem 1 } 


DPI 2.0 MIB 


Overview: An extension to SNMP agents that 
permits end-users to dynamically add or replace 
management variables in the local MIB without 
requiring recompilation of the SNMP agent. 
Although SNMP subagents are supported by an 
AS/400 system, this support does not use the DPI 
2.0 MIB. This is because the AS/400 subagent 
support does not use TCP or UDP between the 
agent and subagents. A transparent, internal 
mechanism is used by the subagents. This MIB is 
supported by the AS/400 SNMP agent even 
though the communication between the agent and 
subagent on the AS/400 does not use TCP or 
UDP. This is done for compatibility. 


This MIB is implemented by the AS/400 system 
but is not currently used. For detail on the MIB, 
see RFC1592. 


RFC: RFC1592 


A-5 


RFC noted exception: None. 


MIB Subtree Description: SNMP Distrib- 
uted Protocol Interface Version 2.0 


MIB Subtree Object Identifier: dpi20MiB 
= {ibmDPI 1 } 


Prerequisite MIB Modules: SNMPv2-SMI 


SNMP Subagent MIB 


-— Note! 


This MIB is experimental and is subject to 
change in future releases. 


Overview: The SNMP subagent MIB provides 
information about subagents to facilitate manage- 
ment activities. The MIB is designed to handle 
multiple types of subagents, including DPI suba- 
gents (see RFC1592), for which the DPI 2.0 API is 
provided. All the SA MIB information is dynamic, 
for the duration of the SNMP agent job. The SA 
MIB consists of six summary OIDs and two tables. 
The summary OIDs are: 


saDefaultTimeout 
default value for subagents for response 
timeout 


saMaxTimeout 
largest value a subagent may use for 
response time-out 


saAllowDuplicatelDs 
flag to allow duplicate subagent OIDs, or not 


saNumber 
number of currently registered subagents 


saAllPacketsIn 
total number of subagent packets that are 
received from all subagents 


saAllPacketsOut 
total number of subagent packets that are 
sent to all subagents. 


The saTable provides information about specific 
subagents such as status, address, and 
description. 

The saTreeTable provides information about spe- 


cific subtrees that subagents have registered with 
the SNMP agent. 


RFC: None 
RFC noted exception: None 


MIB Subtree Description: SNMP suba- 
gent MIB 


MIB Subtree Object Identifier: saMiB ::= 
{ internet(1) private(4) enterprise(1) ibm(2) 
iobmResearch(2) 12 } 


MIB Module Name: IBMSNMPSA 


The ASN.1 for this MIB is available in member 
IBMSNMPSA in file QSYS/QANMMIB. 


Prerequisite MIB Modules: RFC1155, 
RFC1212, RFC1213 
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Appendix B. Journal for SNMP Logging 


This appendix lists the format of journal entries for 
SNMP logging. It also provides examples of dif- 
ferent display journal entries. SNMP agent 
logging records are kept in journal QSNMP in 
library QUSRSYS. Each journal record contains 
118 columns of alphanumeric characters. For 
more information on the use of journals, see the 
Backup and Recovery book. 


The format of journal entries for SNMP agent 
logging is listed below. 


column 1: 


2-21: 
22-33: 


34: 


35-38: 
39: 


40-43: 


44-118: 


log type 
- G: GET request 
- N: GETNEXT request 
- S: SET request 
- R: response 
- T: trap 
community name 
internet address of SNMP manager sending request or receiving 


response, or internet address of first SNMP trap manager 
receiving trap 
error status 
- 0: noError 
- 1: tooBig 
2: noSuchName 
- 3: badValue 
5: genErr 
error index 
trap type 
- 0: coldStart 
warmStart 
TinkDown 
linkUp 
authenticationFailure 
: egpNeighborLoss 


AFPWNEH 


- 6: enterpriseSpecific 
enterprise specific trap type 
NOTE: If the enterprise specific trap type value is less 
than -999, it will be logged as -999. If the 
enterprise specific trap type value is greater than 
9999, it will be logged as 9999. 
object descriptors 


The following examples of journal entries are dis- 
played when using the CL command DSPJRN 
JRN(QUSRSYS/QSNMP). 


e This entry indicates that a GET request speci- 
fying community private was sent by an 
SNMP manager at internet address 
9.130.38.28. The error status, error index, 
and trap type fields all have the value zero. 
The object descriptors that are specified in the 
GET request are shown. 


- Column Kei Pidiesd waste scals sete diede sale hones Aaegatiae sD: 
00001 'Gprivate 9130 38 280 00 OsysUpTi' 
00051 ‘me.0 sysUpTime 
00101 , 
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e This entry is the log of the response to the 


previous GET request. The error status fields 
and error index fields show that the 
noSuchName error was returned for the 
second object that is specified in the GET 


request. 

- Column What ads lesealts the lee wibaeh dewatered ee sheet aD 
00001 "Rprivate 9130 38 282 20 OsysUpTi' 
00051 ‘me.0 sysUpTime 
00101 ! 


This entry indicates that a GETNEXT request 
specifying community private was sent by an 
SNMP manager at internet address 
9.130.38.28. Error status, error index, and the 
trap type fields all have the value zero. The 
object descriptors that are specified in the 
GETNEXT request are shown. 


00001 'Nprivate 9130 38 280 00 Oat atIf' 
00051 "Index.1.1.9.130.25.58 atIfIndex.1.1.9.130.25.195  ' 
00101 : 


This entry is the log of the response to the 
previous GETNEXT request. Other than the 
log type field, only the object descriptors field 
has changed. It now shows the object 
descriptors of the objects that are returned in 
response to the GETNEXT request. Because 
the object descriptor of the third returned 
object cannot completely fit within the 
remaining object descriptors field space, the 
descriptor is not shown at all. 


00001 "Rprivate 9130 38 280 00 QatIfInd' 
00051 "ex.1.1.9.130.25.58 atIfIndex.1.1.9.130.25.195 : 
00101 ' 


This entry indicates that a trap was sent to the 
trap manager at internet address 
9.130.38.154. Error status and error index are 
both zero, and the trap type is linkUp. The 
link that has come online is associated with 
the object descriptor iflndex.3. The trap did 
not specify a community name. 


- Column Kote t deae Li taeattis sre Louis otic t ea Sere gets ee ela eaaittee oe) 


90001 i 9130 381540 03 OifIndex' 
00051 13 
00101 
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Appendix C. Problem Analysis for SNMP 


This appendix is to be used for determining solutions to problems that are encoun- 
tered while using SNMP. 


Problem Analysis for SNMP Agent 


The most common problems, causes, and solutions for the SNMP agent are shown 


in Table C-1. 


Table C-1 (Page 1 of 3). SNMP Agent Problem Analysis 


Problem 


Cause 


Solution 


SNMP agent jobs do not start when the 
STRTCP command runs. 


SNMP agent jobs do not start when the 
STRTCPSVR command runs. 


SNMP managers are not receiving any 
responses from the OS/400 SNMP agent for 
any SET, GET, or GETNEXT requests. 


SNMP attribute AUTOSTART is set to *NO. 


Another application is listening on UDP port 
161. 


The OS/400 SNMP agent is not active. 


The SNMP manager is sending the request 
to a system other than the intended AS/400. 


The SNMP manager is comparing the 
response PDU source IP address with the 
destination IP address in the PDU it sent, 
and they are not equal. 


The SNMP manager is comparing the source 
UDP port number in the response PDU with 
the destination UDP port number (the well- 
known port 161) in the PDU it sent to 
OS/400, and they are not equal. 


The SNMP manager is specifying a commu- 
nity name that is unknown to the OS/400 
SNMP agent. 


Use the CHGSNMPA command to change 
AUTOSTART to *YES. 


Make sure no other applications are using UDP 
port 161 and then start the SNMP agent again 
using the STRTCPSVR command. 


Make sure TCP/IP (or AnyNet) and the OS/400 
SNMP agent are active. The OS/400 SNMP 
agent is active if jobs QTMSNMP and 
QTMSNMPRCV are running in subsystem 
QSYSWRK. Use the WRKACTJOB command 
to determine if these jobs are active. 


Make sure that the SNMP manager is sending 
the request to the intended AS/400. 


The SNMP agent will always send the response 
PDU to the IP address which sent the original 
PDU. Verify, especially for an SNMP manager 
system with multiple IP-addresses, that the 
manager is using the expected IP address. 


The OS/400 SNMP agent does not use UDP 
port 161 to send response PDUs, due to tech- 
nical reasons. The SNMP management appli- 
cation should not check the response PDU port 
number. Instead, the SNMP manager applica- 
tion needs to rely on checking the response 
PDU IP address and, within the PDU, the 
request-id to verify the PDU. 


Make sure that the SNMP manager is speci- 
fying a community name that is known to the 
OS/400 SNMP agent. The list of community 
names may be displayed by using the 
CFGTCPSNMP command. Community names 
are case-sensitive, so make sure that the 
SNMP manager is specifying the community 
name correctly (example: PUBLIC and public 
are two different community names). Also, 
make sure that the value for the Translate com- 
munity name (ASCIICOM) parameter for the 
OS/400 community corresponds to the commu- 
nity name being specified by the SNMP 
manager. If the SNMP manager is an ASCII 
system, the ASCIICOM parameter for the 
OS/400 community should be *YES. If the 
SNMP manager is an EBCDIC system or the 
community name has one or more characters 
that cannot be displayed, the ASCIICOM 
parameter for the OS/400 community should be 
*NO. If the community name or ASCIICOM 
parameter need to be changed, the community 
must be removed by using the RAVCOMSNMP 
command and then added with the correct 
values by using the ADDCOMSNMP command. 
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Table C-1 (Page 2 of 3). SNMP Agent Problem Analysis 


Problem 


Cause 


Solution 


SNMP managers are receiving error responses 
from the OS/400 SNMP agent for GET or 
GETNEXT requests. 


SNMP managers are receiving error responses 
from the OS/400 SNMP agent for SET 
requests. 


SNMP managers are unable to access any 
objects found in the APPN MIB, Client Manage- 
ment MIB, or NetView for AIX MIB. 


The SNMP manager is specifying a commu- 
nity name that is known to the OS/400 
SNMP agent, but the IP address of the 
SNMP manager is not part of the community. 


Object access in the OS/400 community defi- 
nition specifies “NONE. 


Object access in the OS/400 community defi- 
nition specifies *“SNMPATR and object 
access in the OS/400 SNMP attributes is 
*NONE. 


There are problems with the TCP/IP network 
or AnyNet network support. 


The SNMP manager is specifying an incor- 
rect object identifier in the request. 


The SNMP manager is specifying an object 
identifier for an object that is not supported 
by the OS/400 SNMP agent. 


The SNMP manager is specifying an incor- 
rect object identifier in the request. 


The SNMP manager is specifying an object 
identifier for an object that is not supported 
by the OS/400 SNMP agent. 


The SNMP manager is attempting to set an 
object that is defined as read-only. 


The SNMP manager is attempting to set an 
object to a value that is not valid. 


The object access for the community is not 
*WRITE. 


The object access for the community is 
*SNMPATR and the object access in the 
OS/400 SNMP attributes is not *WRITE. 


The OS/400 subagent job is not active. 


The OS/400 subagent job is active, but is 
inactive according to the OS/400 SNMP 
agent. 


Make sure that the IP address of the SNMP 
manager is defined in the OS/400 community. 
If the system the manager is running on has 
multiple IP addresses, ensure that the IP 
address used to send UDP packets to the 
AS/400 agent is the included in the IP 
addresses for the community name configura- 
tion intended for the manager. 


The SNMP agent has the capability to selec- 
tively log (in a journal QSNMP, in library 
QUSRSYS) get and set PDUs and traps. 
When logging get and set PDUs, both the 
incoming and outgoing PDUs are logged. 
These are controlled with the CHGSNMPA and 
CHGCOMSNMP commands. Verify, with the 
SNMP logging capabilities, that the expected 
PDUs are being received and sent by the 
SNMP agent. See Appendix B, “Journal for 
SNMP Logging” on page B-1 for information 
about how to use this function. The IP address 
of the SNMP manager can be added to the 
community by using the CHGCOMSNMP 
command. 


Make sure object access for the community is 
either *READ or *WRITE depending on if you 
desire SET requests to be honored. The object 
access may be changed by using the 
CHGCOMSNMP command. 


See the TCP/IP Configuration and Reference 
for more information about network problem 
analysis. If network problems are suspected, 
use the System Service Tool (STRSST) to gen- 
erate and format a communications trace of 
UDP datagrams, to verify that expected PDUs 
are arriving and being sent by the AS/400. 


Make sure the SNMP manager is specifying an 
object identifier for an object that is supported 
by the OS/400 SNMP agent. 


Make sure the SNMP manager is specifying an 
object identifier for an object that is supported 
by the OS/400 SNMP agent. 


Make sure the SNMP manager is specifying an 
object identifier for an object that can be 
changed. 


Make sure the SNMP manager is specifying a 
valid value for the object. 


Make sure that the object access for the 
OS/400 community is “WRITE. The object 
access for the community may be changed by 
using the CHGCOMSNMP command. The 
object access in the SNMP attributes may be 
changed by using the CHGSNMPA command. 


End the SNMP agent by using the 
ENDTCPSVR command and then start the 
SNMP agent by using the STRTCPSVR 
command. The OS/400 subagent runs in job 
QSNMPSA in subsystem QSYSWRK. Use the 
WRKACTJOB command to determine if this job 
is active. 
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Table C-1 (Page 3 of 3). SNMP Agent Problem Analysis 


Problem 


Cause 


Solution 


Traps are not being received by an SNMP 
manager. 


authenticationFailure traps are not being 
received by an SNMP manager. 


Entries are not being made in journal QSNMP 
in library QUSRSYS for SET requests received 
from SNMP managers. 


Entries are not being made in journal QSNMP 
in library QUSRSYS for GET or GETNEXT 
requests received from SNMP managers. 


Entries are not being made in journal QSNMP 
in library QUSRSYS for traps sent to SNMP 
managers. 


The IP address of the intended SNMP 
manager is not specified correctly in the 
OS/400 SNMP attributes. 


The community name to be placed in the 
trap is not recognized by the SNMP 
manager. 


There are problems with the TCP/IP network 
or AnyNet support. 


The IP address of the intended SNMP 
manager is not specified correctly in the 
OS/400 SNMP attributes. 


The community name to be placed in the 
trap is not recognized by the SNMP 
manager. 


The Send authentication traps 
(SNDAUTTRP) SNMP attribute is specified 
as “NO. 


There are problems with the TCP/IP network 
or AnyNet support. 


SET logging is specified as *NO in the 
OS/400 community definition. 
SET logging is specified as *“SNMPATR in 


the OS/400 community definition and is spec- 
ified as *NO in the OS/400 SNMP attributes. 


GET logging is specified as *NO in the 
OS/400 community definition. 
GET logging is specified as *SNMPATR in 


the OS/400 community definition and is spec- 
ified as *NO in the OS/400 SNMP attributes. 


Trap logging is specified as *NO in the 
OS/400 SNMP attributes. 


Make sure that the IP address of the SNMP 
manager to receive the trap is specified cor- 
rectly in the OS/400 SNMP attributes. The IP 
address of the SNMP manager may be 
changed by using the CHGSNMPA command. 


Make sure the trap community name is speci- 
fied correctly in the OS/400 SNMP attributes. 
The trap community name may be changed by 
using the CHGSNMPA command. 


The SNMP agent has the capability to log traps 
(in journal QSNMP, in library QUSRSYS). This 
is controlled with the CHGSNMPA command. 
Verify, with the SNMP logging capabilities, that 
the expected trap PDUs are being sent by the 
SNMP agent. See Appendix B, “Journal for 
SNMP Logging” on page B-1 for information 
about how to use this function. 


See the TCP/IP Configuration and Reference 
for more information about network problem 
analysis. 


Make sure that the IP address of the SNMP 
manager to receive the trap is specified cor- 
rectly in the OS/400 SNMP attributes. The IP 
address of the SNMP manager may be 
changed by using the CHGSNMPA command. 


Make sure the trap community name is speci- 
fied correctly in the OS/400 SNMP attributes. 
The trap community name may be changed by 
using the CHGSNMPA command. 


Make sure the SNDAUTTRP SNMP attribute is 
specified as *YES. The SNDAUTTRP SNMP 
attribute may be changed by using the 
CHGSNMPA command. 


Verify, with the SNMP trap logging capabilities, 
that the expected trap PDUs are being sent by 
the SNMP agent. See Appendix B, “Journal for 
SNMP Logging” on page B-1 for information 
about how to use this function. 


See the TCP/IP Configuration and Reference 
for more information about network problem 
analysis. 


Make sure that SET logging is specified as 
*YES in the OS/400 SNMP community defi- 
nition. The SET logging for the community may 
be changed by using the CHGCOMSNMP 
command. The SET logging in the SNMP attri- 
butes may be changed by using the 
CHGSNMPA command. 


Make sure that GET logging is specified as 
*YES in the OS/400 SNMP community defi- 
nition. The GET logging for the community may 
be changed by using the CHGCOMSNMP 
command. The GET logging in the SNMP attri- 
butes may be changed by using the 
CHGSNMPA command. 


Make sure that trap logging is specified as 
*YES in the OS/400 SNMP attributes. The trap 
logging in the SNMP attributes may be changed 
by using the CHGSNMPA command. 


Appendix C. Problem Analysis for SNMP C-3 


Problem Analysis for SNMP Manager APIs 


The most common problems, causes, and solutions for the SNMP Management 
application developer are shown in Table C-2. 


Table C-2 (Page 1 of 2). SNMP Management application developer problem analysis 


Problem 


Cause 


Solution 


The SNMP management application received 
an out of memory or out of buffers error. 


The SNMP Management application received 
an out of varBinds error. 


The SNMP Management application received 
an invalid OID error. 


The SNMP Management application receives 
an invalid value error. 


The SNMP Management application receives 
an invalid value representation error. 


The SNMP Management application receives 
an encode or decode error. 


The SNMP Management application received 
an invalid community name length error. 


The SNMP Management application received a 
time-out parameter error. 


The SNMP Management application received 
an unknown host error. 


The SNMP Management application received a 
not OK error. 


SNMP management application receives a 
time-out from the SNMP APIs. 


The SNMP API has run out of resources to 
complete the operation. 


The requested operation has exceeded the 
allowable number of varBinds for a single 
operation. 


An Object IDentifier in the varBind list was 
not specified in the correct dotted decimal 
notation. 


The SNMP API's will do some rudimentary 
checking on the value supplied during a 
snmpSet operation. The API's will detect an 
incorrect length on integer types, and will 
also check for incorrect dotted decimal nota- 
tion on IP addresses and OID's when sup- 
plied as values. 


The ASN type specified for a particular OID 
in the varBind list is not recognized as a 
common ASN type. 


The PDU specified could not be encoded or 
decoded for transmission across the wire. 


The value in community name length field 
was not in the range of 1 to 256. 


The value in the time-out parameter field was 
not in the range of 1 to 100. 


The hostname specified was not recognized 
as a valid host on the network. 


The value length field on a varBind in the 
varBind list was less than 0. 


The time-out value is set too low. 


The SNMP agent receiving the SNMP opera- 
tion is not active. 


The SNMP management application is speci- 
fying a community name that is unknown to 
the SNMP agent. 


The SNMP management application is speci- 
fying a correct community name, but the IP 
address of the manager is not part of the 
community. 


There are problems with the TCP/IP network 
or AnyNet support. 
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The management application can try reducing 
the size of the requested operation. If the 
problem persists, report the error using the 
ANZPRB command. 


The management application can try reducing 
the number of varBinds in the varBind list. 


The management application should specify the 
Object |Dentifier in the correct dotted decimal 
notation. 


The management application should specify the 
value on a set in the correct form as specified 
by the ASN type. 


The management application should specify a 
known ASN type as listed in the QTOMEAPI 
CLEINC file in QSYSINC library. (If you cannot 
locate this file, contact your system support 
department. The QSYSINC library can be 
selectively installed at any time.) 


Retry the command. If the problem persists, 
report the error to IBM using the ANZPRB 
command. 


The management application should specify a 
community name length that is greater than 0 
and less than or equal to 256. 


The management application should specify a 
time-out value that is greater than 0 and less 
than or equal to 100. 


The management application should specify the 
correct hostname, or specify the dotted decimal 
notation of the IP address. 


The management application should specify a 
value field greater than or equal to 0. 


Increase the time-out value and try again. 


Make sure that the receiving agent is active. 


Specify the correct community name. 


Make sure the IP address is know to the SNMP 
agent as a valid SNMP manager. 


See the TCP/IP Configuration and Reference 
for more information about network problem 
analysis. 


Table C-2 (Page 2 of 2). SNMP Management application developer problem analysis 


Problem 


Cause 


Solution 


SNMP management application receives a 
sockets error while trying to initiate a SNMP 
operation. 


SNMP management application receives an 
invalid PDU type. 


SNMP management application receives an 
invalid IP address. 


SNMP management application received a 
Domain Error, Invalid pointer, or Invalid pointer 
type return code from the SNMP APIs. 


SNMP management application received an 
Invalid PDU, Host, Community, or Invalid 
pointer type return code from the SNMP APIs. 


SNMP management application received a 
Return code 1 from the APIs. 


SNMP management application receives a non- 
zero return status in the Error Status field of the 
SNMP PDU on a Get or GetNext operation. 


SNMP management application receives a non- 
zero return status in the Error Status field of the 
SNMP PDU on a Set operation. 


The SNMP API could not connect properly to 
sockets to perform its operation across 
TCP/IP or AnyNet. 


The SNMP management application tried to 
issue an SNMP operation of one type while 
specifying a PDU built for another type. 


The SNMP management application tried to 
issue an SNMP operation with an 
unrecognizable IP address. 


The SNMP management application speci- 
fied a pointer which caused an object domain 
error, reference location in a space that does 
not contain a pointer, or the pointer refer- 
enced storage in system state. These errors 
are equivalent to escape messages 
MCH6801, MCH3601, and MCH3602. 


The SNMP management application speci- 
fied a Null pointer. 


This states that the amount of space allo- 
cated for the value returned in one or more 
varBinds, for a GET or GETNEXT operation, 
was not sufficient. 


The SNMP agent could not fit the contents of 
the returned data in the SNMP message. 


The SNMP management application is speci- 
fying an incorrect object identifier in the 
request. 


The SNMP management application is speci- 
fying an object identifier that is not supported 
by the receiving SNMP agent or its suba- 
gents. 


The SNMP management application is speci- 
fying an incorrect object identifier in the 
request. 


The SNMP management application is speci- 
fying an object identifier that is not supported 
by the receiving SNMP agent or its suba- 
gents. 


The SNMP management application is 
attempting to set and object that is defined 
as read-only. 


The SNMP management application is 
attempting to set an object value that is not 
valid. This value could be the incorrect ASN 
syntax, or it may not be in the acceptable 
range of values. 


Make sure TCP/IP support or AnyNet support is 
active on the system, and then retry the 
command. 


Make sure that the PDU type matches that of 
the SNMP operation being performed. 


Make sure that the IP address is either in the 
Hostname form or in the dotted decimal form. 
(example of hostname form: host.city.state) 
(example of dotted decimal form: 9.9.9.9) 


The SNMP management application should not 
use system state references, retry the operation 
passing in a valid pointer to user state storage. 
See the previously discussed message 
descriptions for further information. 


The SNMP management application should use 
a non-NULL pointer. 


The SNMP management application should 
specify a greater value in the val_len field of the 
_varBind structure. 


If the management application specified more 
than one object identifier to retrieve, then 
reduce the number of object identifiers until the 
returned data fits into a SNMP message. 


Make sure that the SNMP management appli- 
cation is specifying an object identifier for an 
object that is supported by the receiving SNMP 
agent or its subagents. 


Make sure the SNMP manager is specifying an 
object identifier for an object that is supported 
by the receiving SNMP agent or its subagents. 


Make sure that the SNMP management appli- 
cation is specifying an object identifier for an 
object that can be changed. 


Make sure that the SNMP management appli- 
cation is specifying the correct ASN syntax in 
the ASN type field. Also, Make sure that the 
SNMP management application is specifying 
the value with the acceptable range. 


Problem Analysis for SNMP Trap Manager 


The most common problems, causes, and solutions for the SNMP trap manager 
are shown in Table C-3 on page C-6. 
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Table C-3. SNMP Trap Manager Problem Analysis 


Problem 


Cause 


Solution 


SNMP trap manager jobs do not start when the 
STRTRPMGR command runs. 


Traps are not being received by the SNMP trap 
manager. 


Traps are not being forwarded to other SNMP 
manager systems. 


Jobs QTMSNMP, QTMSNMPRCV, 
QTRAPMGR, and QTRAPMGRRCV in sub- 
system QSYSWRK are consuming a large 
amount of processor resource. 


Another application is listening on UDP port 
162. 


The IP address of this system is not speci- 
fied correctly on the SNMP agent system 
sending the trap. 


There are problems with the TCP/IP network 
or AnyNet support. 


The IP address of the intended SNMP 
manager is not specified correctly in the 
OS/400 SNMP attributes. 


The community name to be placed in the 
trap is not recognized by the SNMP 
manager. 


Trap forwarding was not specified when the 
SNMP trap manager was started on this 
system. 


The SNMP agent on this system is not 
active. 


There are problems with the TCP/IP network 
or AnyNet support. 


It is possible that this may be caused by trap 
forwarding being specified and the IP 
address of this system being listed as a trap 
manager in the OS/400 SNMP attributes. 


It is possible that this system is part of a ring 
of trap managers in your network that 
forward traps to each other. 


Make sure no other applications are using UDP 
port 162 and then start the SNMP trap manager 
again using the STRTRPMGR command. 


Make sure that the IP address of this system is 
specified correctly on the SNMP agent system. 


See the TCP/IP Configuration and Reference 
for more information about network problem 
analysis. 


Make sure that the IP address of the SNMP 
manager to receive the trap is specified cor- 
rectly in the OS/400 SNMP attributes. The IP 
address of the SNMP manager may be 
changed by using the CHGSNMPA command. 


Make sure the trap community name is speci- 
fied correctly in the OS/400 SNMP attributes. 
The trap community name may be changed by 
using the CHGSNMPA command. 


Make sure that trap forwarding is specified 
when the SNMP trap manager is started. The 
SNMP trap manager is started by using the 
STRTRPMGR command. 


Make sure the SNMP agent is active. The 
OS/400 SNMP agent is active if jobs 
QTMSNMP and QTMSNMPRCV are running in 
subsystem QSYSWRK. Use the WRKACTJOB 
command to determine if these jobs are active. 


See the TCP/IP Configuration and Reference 
for more information about network problem 
analysis. 


Do one or more of the following: 


¢ Turn off trap forwarding by ending the trap 
manager using the ENDTRPMGR 
command. Then start the trap manager 
using the STRTRPMGR command with trap 
forwarding specified as *NO. 


¢ Remove the IP address of this system from 
the trap manager list in the OS/400 SNMP 
attributes using the CHGSNMPA command. 


¢ Make sure there are no rings of trap man- 
agers in your network. 


Problem Analysis for SNMP Subagent APIs 


The most common problems, causes, and solutions for the SNMP subagent devel- 
oper are shown in Table C-4. 


Table C-4 (Page 1 of 3). SNMP subagent developer problem analysis 


Problem 


A SNMP subagent cannot ‘connect’ to the 
SNMP agent. 


Cause 


SNMP agent job is not running. 


Solution 


Make sure the SNMP agent job on the AS/400 
(QTCP/QTMSNMP) is running. (Use the 
WRKACTJOB CL command. Another way to 
check is to send a SNMP ‘get' request for some 
easy OID (for example, sysContact.0) using a 
SNMP manager or a utility such as snmpinfo 
(widely available on Unix systems).) 
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Table C-4 (Page 2 of 3). SNMP subagent developer problem analysis 


Problem 


Cause 


Solution 


The SNMP subagent is unable to successfully 
perform the open function 


The SNMP subagent is unable to successfully 
perform the register function. 


A return code of snmpsa_RC_timedout was 
returned by connectSNMP(). 


A return code of snmpsa_RC_parmerr was 
returned by connectSNMP(). 


The subagent receives a NULL pointer from 
the mkDPlopen() routine. 


The subagent cannot send the DPI open 
packet. 


The subagent receives an 
SNMP_ERROR_DPI_otherError (101) in the 
DPI response packet from the agent. 


The subagent receives an 
SNMP_ERROR_DPI_duplicate- 
Subagentldentifier (109) in the DPI response 
packet from the agent. 


The subagent receives a NULL pointer from 
the mkDPlregister() routine. 


The subagent receives an 
SNMP_ERROR_DPI_otherError (101) in the 
DPI response packet from the agent. 


The subagent receives an 
SNMP_ERROR_DPI_alreadyRegistered 
(103) in the DPI response packet from the 
agent. 


The subagent receives an 
SNMP_ERROR_DPI_higher- 
priorityRegistered (104) in the DPI response 
packet from the agent. 


Make sure that the duration of the time-out (the 
third parameter) is not too small, with respect to 
system load. Generally, 20 or so should be suf- 
ficient. 


Make sure the data queue and library name 
parameters are not NULL pointers and are 
between 1 and 10 bytes in length, and specify 
valid library and queue names. 


Verify that the library name is not QTEMP. 


A NULL pointer from mkDPlopen() is usually 
caused by a simple error in one of the parame- 
ters. Verify that each of the parameters in the 
call are correct. 


Verify that the subagent OID does not violate 
SNMPv2 limits; no more than 128 subids and 
each subid must be representable in a 32-bit 
unsigned integer field. 


Verify that prior to calling sendDPlpacket(), a 
call has successfully been made to the 
connectSNMP() routine. 


An SNMP_ERROR_DPI_otherError (101) in the 
DPI response packet from the agent usually 
occurs due to some invalid value in the DPI 
open packet. For example, the subagent's OID 
must be null terminated and end with a subid, 
not a'.'. 

The subagent receives a 
SNMP_ERROR_DPI_duplicate- 
Subagentldentifier (109) when the SNMP agent 
already has a active subagent with the same 
OID, and the subagent MIB 
saAllowDuplicatelDs is set to 2. Either change 
the OID the subagent uses in the mkDPlopen() 
call, or change the subagent MIB 
saAllowDuplicatelDs to 1 to allow duplicates. 


A NULL return usually indicates some param- 
eter error. Check the subagent's job log for 
exceptions. If any are found, correct them, 
rebuild the subagent code and try the call 
again. If no exceptions are found, verify that the 
parameters are valid (for example, group_p is 
not NULL). 


The most common cause of an 
SNMP_ERROR_DPI_otherError (101) in 
response to a DPI register packet is that the 
subtree OID did not end with a '.'; verify that the 
subtree OID ends with a". 


The most common cause of an 
SNMP_ERROR_DPI_alreadyRegistered (103) 
error is that the subagent attempted to register 
a subtree that would cause a protected subtree 
to be affected. Verify that the subtree to be 
registered (parameter group_p in the 
mkDPlregister() call) is not above, at, or within 
one of the SNMP agent's protected subtrees 
(see the list of these in the mkDPlregister() API 
documentation). 


For an SNMP_ERROR_DPI_higher- 
priorityRegistered (104), re-request the subtree 
registration with a higher priority or 0 (which 
requests the highest). If the already registered 
subagent has priority 0 (get the subagent MIB 
saTstatus for the subtree), then there is no 
higher priority to request, so the other subtree 
must be unregistered or its subagent end 
before you can register the subtree. 
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Table C-4 (Page 3 of 3). SNMP subagent developer problem analysis 


Problem 


Cause 


Solution 


The SNMP subagent has successfully done 
connect, open and register, but does not 
receive any DPI packets (from the SNMP 
agent). 


The SNMP subagent works for awhile, but then 
mkDPIset() return NULL, when trying to build 
structure for a response packet. 


The SNMP subagent works for awhile, but then 
pDPlpacket() returns NULL, when trying to 
parse a new incoming DPI packet. 


The SNMP subagent occasionally gets a DPI 
unregister or close packet from the agent with 
reason_code of SNMP_UNREGISTER_time-out 
or SNMP_CLOSE_time-out. 


The SNMP subagent gets a snmpsa_RC_err 
return code. 


The SNMP agent job is not running. 


There have not been any SNMP PDUs for 
the subtrees registered by the subagent. 


The subagent or the subagent's subtree reg- 
istration status is not 'valid' (1). 


There is insufficient memory to build the 
internal structures for the DPI packet, 
because it has not been freed, after having 
been dynamically allocated. 


Some other exception condition occurred. 


There is insufficient memory to build the 
internal structures for the DPI packet, 
because it has not been freed, after having 
been dynamically allocated. 


Some other exception condition occurred. 


The subagent has taken too long to respond 
to some SNMP agent request. That is, longer 
than the time-out value used by the subagent 
in the mkDPlopen() or mkDPlregister() calls. 


A run-time exception occurred, which is not 
covered by some other, more specific, return 
code. 


Make sure the SNMP agent job on the AS/400 
(QTCP/QTMSNMP) is running (use the 
WRKACTJOB CL command) and responding to 
PDUs in a normal way. 


Verify that a SNMP PDU (Get, Getnext or Set) 
for an OID in the subagent's subtree, has been 
sent to the SNMP agent. 


Check the status OIDs in the subagent MIB and 
verify the values are 'valid' (1). These OIDs are 
in the SNMP subagent MIB in the saTable and 
saTreeTable, and are the saStatus OID (for the 
right subagent) and saTstatus OID (for the right 
subtree). (The ASN.1 definition for the suba- 
gent MIB can be found in QSYS/QANMMIB, 
member IBMSNMPSA.) 


Ensure that the fDPlset() routine is called so 
that memory use does not monotonically 
increase while the subagent is running. (see 
“Simple Network Management Protocol (SNMP) 
Subagent APIs” in the book System API 
Reference: UNIX-Type APIs. 


See the messages in the job logs for both the 
SNMP agent job (QTCP/QTMSNMP) and the 
subagent job. Correct them and retry the suba- 
gent job. 


Ensure that the fDPlparse() routine is called so 
that memory use does not monotonically 
increase while the subagent is running. (see 
“Simple Network Management Protocol (SNMP) 
Subagent APIs” in the book System API 
Reference: UNIX-Type APIs. 


See the messages in the job logs for both the 
SNMP agent job (QTCP/QTMSNMP) and the 
subagent job. Correct them and retry the suba- 
gent job. 


Re-open or re-register with a longer time-out, or 
use a smaller max_varBinds value in the 
mkDPlopen() call, or both. Important note: the 
entire SNMP agent waits for up to the time-out 
value for a response to each DPI request. If 
requests for a particular OID or subagent 
subtree takes a long time (relatively) for the 
subagent to process, then consideration should 
be given to registering that OID or subtree sep- 
arately (by the same subagent), with a appropri- 
ately longer time-out. 


See the messages in the job logs for both the 
SNMP agent job (QTCP/QTMSNMP) and the 
subagent job (that received the snmpsa_RC_err 
return code) for exceptions. Correct them and 
retry the subagent API calls. (By its nature this 
return code is fairly rare, and the cause for the 
exception is usually obvious, in either the agent 
or the subagent job.) 
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ADDCOMSNMP 


Appendix D. CL Commands for AS/400 SNMP 


This section provides syntax diagrams and explanations of the CL commands for AS/400 SNMP. 


ADDCOMSNMP (Add Community for SNMP) Command 


>>—ADDCOMSNMP—COM(—communi ty-name—) —? 


Job: B,| Pgm: B,| REXX:B,l Exec 


*YES 
Peers ee 


> 
* ANY: i --*SNMPATR- 
OBJACC (—+—*READ ) 
INTNETADR(—L-¥-manager-internet-address ) *WRITE 


*NONE 


>< 


> 
| *SNMPATR— | aes Leal | 
LOGSET( {aves ) Loccet(—t «ves ) 
*NO: *NO 


Notes: 


P All parameters preceding this point can be specified in positional form. 


1 A maximum of 300 repetitions. 


Purpose 


The Add Community for SNMP (ADDCOMSNMP) 
command defines an SNMP community profile 
and adds it to the SNMP agent community list. 
An SNMP agent uses a community profile to 
determine whether or not to honor a request sent 
by an SNMP manager. The community profile 
consists of a community name, an object access 
specification, and a list of the SNMP managers 
that are part of the community. The combination 
of the community name (COM) and the translate 
to ASCII community (ASCIICOM) parameters 
defines a community. 


Multiple community profiles, each having a unique 
community name may exist in the SNMP agent 
community list at one time. Similarly, the same 
internet address may appear in more than one 
community profile. 


The OS/400* SNMP agent does not support com- 
munity views. A view is a subset of the objects in 
the management information base (MIB). Each 
OS/400 community consists of all of the objects in 
the MIB. 


Restrictions: An SNMP manager sends three 
types of requests: get, get-next, and set. Get and 
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get-next requests are used to read management 
information base (MIB) variables, and a set 
request is used to modify MIB variables. Fora 
request from an SNMP manager to be accepted 
by the AS/400 SNMP agent, all of the following 
must be true: 


1. The community name in the SNMP manager 
request specifies a defined community. 


2. The internet address of the manager that sent 
the request must be listed in the community 
profile. 


3. For a set request, the community object 
access must allow write operations to occur. 
For a get request or get-next request, read 
operations must be allowed. 


4. For a set request, the object specified in the 
request must be able to be changed. Fora 
get request or get-next request, the object 
must be readable. 


Required Parameter 


COM 
Specifies the name of the SNMP community 
being added. Each SNMP community name 
must be unique. 


D-1 


ADDCOMSNMP 


community-name: Specify the name of the 
SNMP community being added. The name 
may contain characters that cannot be dis- 
played (for example, X'60619E'). 


Optional Parameters 
ASCIICOM 


Specifies whether the community name is 
translated to ASCII characters when the com- 
munity profile is added to the SNMP agent 
community list. 


*YES: The community name is translated to 
ASCII characters when the community profile 
is added to the SNMP agent community list. 
This value should be specified if the SNMP 
manager system defines its community names 
entirely of ASCII characters. An error 
message is sent if the community name 
cannot be translated to ASCII characters. 


*NO: The community name is not translated 
to ASCII characters when the community 
profile is added to the SNMP agent commu- 
nity list. This value should be specified if the 
SNMP manager system defines its community 
names using EBCDIC characters or charac- 
ters that cannot be displayed. 


INTNETADR 


Specifies the internet addresses of the SNMP 
managers that are part of this community. 


*ANY: Allow any SNMP manager to be part 
of this community. 


manager-internet-address: Specify the 
internet address of the SNMP manager. The 
internet address is specified in the form 
nnn.nnn.nnn.nnn, where nnn is a decimal 
number ranging from 0 through 255. An 
internet address is not valid if it has a value of 
all binary ones or all binary zeros for the 
network identifier (ID) portion or the host ID 
portion of the address. If the internet address 
is entered from a command line, the address 
must be enclosed in apostrophes. Up to 300 
unique internet addresses may be specified. 
The same internet address may appear in 
more than one community profile. 


OBJACC 


Specifies the object access for the community. 
*SNMPATR: The object access defined with 


the Change SNMP Attributes (CHGSNMPA) 
command is used for this community. 


*READ: Allow SNMP managers that are part 
of this community to read all management 
information base (MIB) objects with get or get- 
next requests. Modification of MIB objects by 
SNMP managers is not permitted. 


*WRITE: Allow SNMP managers that are part 
of this community to change all MIB objects 
that are able to change with set requests. 
Specifying *WRITE implies “~READ access. 


*NONE: Do not allow SNMP managers that 
are part of this community any access to MIB 
objects. 


LOGSET 
Specifies whether set requests from SNMP 
managers in this community are logged in 
journal QSNMP in library QUSRSYS. 


*SNMPATR: The value defined with the 
Change SNMP Attributes (CHGSNMPA) 
command is used for this community. 


*YES: Set requests are logged. 
*NO: Set requests are not logged. 


LOGGET 
Specifies whether get requests and get-next 
requests from SNMP managers in this com- 
munity are logged in journal QSNMP in library 
QUSRSYS. 


*SNMPATR: The value defined with the 
Change SNMP Attributes (CHGSNMPA) 
command is used for this community. 


*YES: Get requests and get-next requests 
are logged. 


*NO: Get requests and get-next requests are 
not logged. 


Example 


ADDCOMSNMP = COM(ROCHESTER) 
INTNETADR('8.6.5.4' '8.6.5.3') 
OBJACC (*WRITE) 


This command adds the community ROCHESTER 
to the SNMP agent community list. SNMP man- 
agers with internet addresses 8.6.5.4 and 8.6.5.3 
are the only managers in the community and are 
able to change all MIB objects. 
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CFGTCPSNMP 


CFGTCPSNMP (Configure TCP/IP SNMP) Command 


Job: | Pgm: | REXX: I Exec 


>>—CFGTCPSNMP. >< 
Purpose INTNETADR “ANY 
OBJACC “READ 
The Configure TCP/IP SNMP (CFGTCPSNMP) 
command is used to display a menu that allows a LOGSET NO 
user to define or change the Simple Network Man- LOGGET *NO 


agement Protocol (SNMP) configuration. The 
menu options include: 


e Change SNMP attributes 

¢ Work with communities for SNMP 
It is not necessary to run the CFGTCPSNMP 
command before using the SNMP agent. The 


SNMP agent is shipped with a community that has 
the following characteristics: 


Community Name _ public 
ASCIICOM *YES 


See the Change SNMP Attributes (CHGSNMPA) 
command for the default values for SNMP attri- 
butes. 


There are no parameters for this command. 


Example 
CFGTCPSNMP 


This command displays the Configure TCP/IP 
SNMP menu. 
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CHGCOMSNMP 


CHGCOMSNMP (Change Community for SNMP) Command 


Job: B,| Pgm: B,| REXX:B,l Exec 


>>—CHGCOMSNMP—COM(—community-name—)—” 


it *YES 
ASCIICOM( «NO: ) 
> > 
i “* SAME | | -—* SAME 
INTNETADR( *ANY ) OBJACC ( *SNMPATR j+ 
Ee --*READ 
anager-internet-address t-*WRITE 
—*NONE 


> 
L *SAME 
LOGSET (—+—*SNMPATR-+—) 


Notes: 


* SAME | 
LOGGET( oS 
*YES *YES 
*NO *NO: 


>< 


P All parameters preceding this point can be specified in positional form. 


1 A maximum of 300 repetitions. 


Purpose 


The Change Community for SNMP 
(CHGCOMSNMP) command changes an SNMP 
community profile in the SNMP agent community 
list. An SNMP agent uses a community profile to 
determine whether or not to honor a request sent 
by an SNMP manager. The community profile 
consists of a community name, an object access 
specification, and a list of the SNMP managers 
that are part of the community. The combination 
of the community name (COM) and the translate 
to ASCII community (ASCIICOM) parameters 
defines a community. 


Required Parameter 


COM 
Specifies the name of the SNMP community 
being changed. The community must already 
exist in the SNMP agent community list. You 
can define an SNMP community using the 
Add Community for SNMP (ADDCOMSNMP) 
command. 


community-name: Specify the name of the 
SNMP community being changed. The name 
may contain characters that cannot be dis- 
played. 


Optional Parameters 


ASCIICOM 
Specifies whether the community name is 
translated to ASCII characters before it is 
compared with the community name specified 
in a request from an SNMP manager. This 
parameter is used in combination with the 
community name to determine the community 
to be changed. If this parameter is not speci- 
fied and two communities have the same 
name but different ASCIICOM parameter 
values, the community that is changed is the 
community with ASCIICOM set to *YES. 


*YES: The community name is translated to 
ASCII characters before it is compared with a 
community name specified by an SNMP 
manager. 


*NO: The community name is not translated 
to ASCII characters before it is compared with 
a community name specified by an SNMP 
manager. 


INTNETADR 
The internet addresses of the SNMP man- 
agers that are part of this community. 


*SAME: The value does not change. 


*ANY: Allow any SNMP manager to be part 
of this community. 


manager-internet-address: Specify the 
internet address of the SNMP manager. The 
internet address is specified in the form 
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nnn.nnn.nnn.nnn, where nnn is a decimal 
number ranging from 0 through 255. An 
internet address is not valid if it has a value of 
all binary ones or all binary zeros for the 
network identifier (ID) portion or the host ID 
portion of the address. If the internet address 
is entered from a command line, the address 
must be enclosed in apostrophes. Up to 300 
unique internet addresses may be specified. 
The same internet address may appear in 
more than one community profile. 


OBJACC 


Specifies the object access for the community. 
*SAME: The value does not change. 


*SNMPATR: The object access defined with 
the Change SNMP Attributes (CHGSNMPA) 
command is used for this community. 


*READ: Allow SNMP managers that are part 
of this community to read all management 
information base (MIB) objects. Modification 
of MIB objects by SNMP managers is not per- 
mitted. 


*WRITE: Allow SNMP managers that are part 
of this community to change all MIB objects 
that can be changed. Specifying *WRITE 
implies *~READ access. 


*NONE: Do not allow SNMP managers that 
are part of this community to access any MIB 
objects. 


LOGSET 


Specifies whether Set requests from SNMP 
managers in this community are logged in 
journal QSNMP in library QUSRSYS. 


CHGCOMSNMP 


*SAME: The value does not change. 


*SNMPATR: The value defined with the 
Change SNMP Attributes (CHGSNMPA) 
command is used for this community. 


*YES: Set requests are logged. 
*NO: Set requests are not logged. 


LOGGET 
Specifies whether get requests and get-next 
requests from SNMP managers in this com- 
munity are logged in journal QSNMP in library 
QUSRSYS. 


*SAME: The value does not change. 


*SNMPATR: The value defined with the 
Change SNMP Attributes (CHGSNMPA) 
command is used for this community. 


*YES: Get requests and get-next requests 
are logged. 


*NO: Get requests and get-next requests are 
not logged. 


Example 


CHGCOMSNMP = COM(ENDICOTT) INTNETADR(*ANY) 
OBJACC (*READ) 


This command changes community ENDICOTT to 
have an object access of read and to allow any 
SNMP manager to read the MIB objects on this 
system. All of the other community values are 
unchanged. 
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CHGSNMPA 


CHGSNMPA (Change SNMP Attributes) Command 


Job: B,| Pgm: B,| REXX:B,Il Exec 


>>—CHGSNMPA > 
* SAME | | * SAME | 
_SYSCONTACT ( *NONE ) SYSLOC ( *NONE ) 
*CNTINF *CNTINF: 
—system-contact— '—system-location 
> > 
i fp ToAMeS | * SAME: | | -—* SAME: | 
SNDAUTTRP( ms ) AUTOSTART ( {aves ) OBJACC (—+-*READ ) 
+*NO— «NO |-*WRITE 
—*NONE 
> > 
| * SAME: | * SAME | * SAME | 
LOGSET ( *YES ) LOGGET ( *YES ) LOGTRP( | «ves ) 
*NO *NO «NO 
> >< 
| * SAME: | 
TRPMGR (—+—*NONE | ) 
LF ehaders internet address —eonmintey crane E )— 
—*YES 
—*NO 
Note: 
1 A maximum of 300 repetitions. 
SYSCONTACT 


Purpose 


The Change SNMP Attributes (CHGSNMPA) 
command changes values and options used by 
the OS/400 SNMP agent. The command also is 
used to specify which SNMP managers receive 
traps generated by the local AS/400 system. 


The SNMP agent is shipped with the following 
values for the SNMP attributes. 


Keyword Value 
SYSCONTACT “NONE 
SYSLOC *NONE 
SNDAUTTRP “YES 
AUTOSTART *NO 
OBJACC *READ 
LOGSET *NO 
LOGGET *NO 
LOGTRP *“NO 
TRPMGR “NONE 


Optional Parameters 


Specifies the name of the contact person for 
this AS/400 system, along with information on 
how to contact this person. This value is used 
only by SNMP-specific functions. This value 
also may be read or modified by an author- 
ized SNMP manager. 


*SAME: The value does not change. 
*NONE: No system contact exists. 


*CNTINF: The value is obtained from the 
service contact information specified by using 
the Work with Contact Information 
(WRKCNTINF) command. The value obtained 
consists of the contact person and the contact 
telephone numbers. 


system-contact: Specify the name of the 
contact person and other contact information. 
All of the characters specified must be able to 
be translated into the ASCII character set. 


SYSLOC 


Specifies the physical location of this AS/400 
system. This value is used only by 
SNMP-specific functions. This value also may 
be read or modified by an authorized SNMP 
manager. 
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*SAME: The value does not change. 


*NONE: No system location information 
exists. 


*CNTINF: The value is obtained from the 
service contact information specified by using 
the Work with Contact Information 
(WRKCNTINF) command. The value obtained 
consists of the mailing address. 


system-location: Specify the physical location 
of the system. All of the characters specified 
must be able to be translated into the ASCII 
character set. 


SNDAUTTRP 


Specifies whether the SNMP agent may send 
any authenticationFailure traps to any defined 
SNMP managers. An authenticationFailure 
trap is sent by the SNMP agent if a request is 
received from an SNMP manager that con- 
tains a community name that is not recog- 
nized by the SNMP agent. This trap is only 
sent when SNDAUTTRP is *YES and when at 
least one trap manager has been defined. 
This value may also be read or modified by an 
authorized SNMP manager. 


*SAME: The value does not change. 


*YES: authenticationFailure traps may be 
sent. 


*NO: authenticationFailure traps are not sent. 


AUTOSTART 


Specifies whether the SNMP agent is started 
when the STRTCP command runs. 


*SAME: The value does not change. 


*YES: The SNMP agent is started when the 
STRTCP command runs. 


*NO: The SNMP agent is not started when 
the STRTCP command runs. 


OBJACC 


Specifies the default object access for SNMP 
communities. 


*SAME: The value does not change. 


*READ: Allow SNMP managers that are part 
of a community to read all management infor- 
mation base (MIB) objects. Modification of 
MIB objects by SNMP managers is not per- 
mitted. 


CHGSNMPA 


*WRITE: Allow SNMP managers that are part 
of a community to modify all MIB objects that 
can be modified. Specifying “WRITE implies 
“READ access. 


*NONE: Do not allow SNMP managers that 
are part of a community to modify any MIB 
objects. 


LOGSET 


Specifies the default value for whether set 
requests from SNMP managers in a commu- 
nity are logged in journal QSNMP in library 
QUSRSYS. 


*SAME: The value does not change. 
*YES: Set requests are logged. 


*NO: Set requests are not logged. 


LOGGET 


Specifies the default value for whether get 
requests and get-next requests from SNMP 
managers in a community are logged in 
journal QSNMP in library QUSRSYS. 


*SAME: The value does not change. 


*YES: Get requests and get-next requests 
are logged. 


*NO: Get requests and get-next requests are 
not logged. 


LOGTRP 


Specifies whether traps are logged in journal 
QSNMP in library QUSRSYS. 


*SAME: The value does not change. 
*YES: Traps are logged. 
*NO: Traps are not logged. 


TRPMGR 


Specifies which SNMP managers receive 
traps generated by this AS/400 system. 


*SAME: The value does not change. 
*NONE: No SNMP managers receive traps. 
Element 1: Manager Internet Address 


manager-internet-address: Specify the 
internet address of the SNMP manager. The 
address must be of the form nnon.nnn.nnn.nnn, 
where nnn is a decimal number ranging from 
0 to 255. This address is independent of the 
manager internet address specified on the 
ADDCOMSNMP and CHGCOMSNMP com- 
mands. 
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CHGSNMPA 


Element 2: Community Name 


community-name: Specify the SNMP commu- 
nity name to be placed in the traps sent to this 
SNMP manager. The community name speci- 
fied in this element is independent of the com- 
munity name specified on the 
ADDCOMSNMP, CHGCOMSNWMP, and 
RMVCOMSNMP commands. The name may 
contain characters that cannot be displayed. 


Element 3: Translate Community Name 


*YES: The community name is translated to 
ASCII characters when a trap is sent to the 
SNMP manager. This value should be speci- 
fied when the community name consists 
entirely of characters that can be displayed. 
An error message is sent if the community 
name cannot be translated to ASCII charac- 
ters. 


*NO: The community name is not translated 
to ASCII characters when a trap is sent to the 
SNMP manager. This value should be speci- 
fied when the community name contains one 
or more characters that cannot be displayed. 


Examples 


Example 1: Changing System Contact and 
Automatic Start 


CHGSNMPA = SYSCONTACT('JOE SMITH, PHONE 555-1212') 
AUTOSTART (*NO) 


This command changes the system contact infor- 
mation and specifies that the SNMP agent should 
not start when the STRTCP command runs. All 
other values are unchanged. 


Example 2: Changing Trap Managers 


CHGSNMPA = TRPMGR(('9.8.7.6' 'TRAPCOMMUNITY ') 
('9.8.7.5' 'TRAPCOMMUNITY2')) 


This command causes any traps generated by the 
local AS/400 system to be sent to SNMP man- 
agers that have internet protocol addresses 
9.8.7.6 and 9.8.7.5. Community name 
TRAPCOMMUNITY is placed in traps sent to 
9.8.7.6, and community name 
TRAPCOMMUNITY2 is placed in traps sent to 
9.8.7.5. For both managers the community name 
is translated to ASCII characters before being 
placed in the trap. 
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ENDTCPSVR 


ENDTCPSVR (End TCP/IP Server) Command 


Job: B,| Pgm: B,| REXX:B,Il Exec 


*ALL 


L * SNMP. { 


>>—ENDTCPSVR f 
SERVER( 


*TELNET 
|_»FTP——| 
«SMTP 
L_+LPpD——! 


Notes: 
1 A maximum of 5 repetitions. 


P All parameters preceding this point can be specified in positional form. 


Purpose 


The ENDTCPSVR command is used to end the 


*TELNET: All TELNET server jobs are 
ended. 


*FTP: All FTP server jobs are ended. 


TCP/IP application server jobs that are specified in 


the SERVER parameter. If the jobs have any 


*SMTP: All jobs associated with SMTP in the 


current active connections, these connections are QSYSWRK subsystem are ended. The bridge 


ended immediately. If the ENDTCPSVR 
command is used to end a server that is not 
active, a diagnostic message is returned. 


Optional Parameter 


SERVER 
Specifies which of the TCP/IP application 


server jobs is to be ended by this command. 


*ALL: All of the TCP/IP server jobs are 
ended. 


*SNMP: All jobs associated with the SNMP 
agent in the QSYSWRK subsystem are 
ended. 


job in the QSNADS subsystem is not ended. 
*LPD: All LPD server jobs are ended. 
Examples 


Example 1: Ending All TCP/IP Servers 
ENDTCPSVR 


This command ends all active TCP/IP application 
server jobs running in the QSYSWRK subsystem. 


Example 2: Ending the LPD Servers 
ENDTCPSVR SERVER(*LPD) 


This command ends the TCP/IP LPD application 
server jobs. 
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ENDTRPMGR 


ENDTRPMGR (End Trap Manager) Command 


Job: B,| Pgm: B,| REXX:B,l Exec 


>< 


>>—ENDTRPMGR 


Purpose 

The End Trap Manager (ENDTRPMGR) command 
allows you to end the OS/400 SNMP Manager 
Framework trap manager job. 


There are no parameters for this command. 
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STRTCPSVR 


STRTCPSVR (Start TCP/IP Server) Command 


Job: B,| Pgm: B,| REXX:B,Il Exec 


*ALL 


L * SNMP. { 


*TELNET 
|_»FTP——| 

«SMTP 
L_+LPpD——! 


>>—STRTCPSVR | 
SERVER( 


— 


Notes: 
1 A maximum of 5 repetitions. 


>< 


P All parameters preceding this point can be specified in positional form. 


Purpose 


The Start TCP/IP Server (STRTCPSVR) command 
is used to start the TCP/IP application servers that 
are shipped with the Operating System/400 
product or the TCP/IP Connectivity Utilities/400 
product. This command starts TCP/IP jobs in the 
QSYSWRK subsystem for the application servers 
specified with the server (SERVER) parameter. 
The number of server jobs started by this 
command is specified, where appropriate, in the 
configuration for each TCP/IP application. 


All servers have an autostart (AUTOSTART) 
parameter on the associated configuration 
command (for example, Change FTP Attributes 
(CHGFTPA)). This parameter indicates if the 
server should be started when the Start TCP/IP 
(STRTCP) command is entered. The 
STRTCPSVR command ignores the value of a 
server's autostart parameter. 


Optional Parameter 


SERVER 
Specifies the TCP/IP application servers to be 
started by this command. 


*ALL: All of the TCP/IP application servers 
are started. 


*SNMP: The Simple Network Management 
Protocol (SNMP) agent jobs are started. Sub- 
sequent usage of the STRTCPSVR 
SERVER(*SNMP) command results in a diag- 
nostic message if the SNMP server jobs have 
already been started. 


*TELNET: The TELNET server is started. 
Subsequent usage of the STRTCPSVR 
SERVER(*TELNET) command starts one 
additional TELNET server. 


Note: Having more than one TELNET server 
job running reduces the chances of 
having connection attempts refused. 


*FTP: The File Transfer Protocol (FTP) 
servers are started based on the number of 
servers configured with the Change FTP Attri- 
butes (CHGFTPA) command. Subsequent 
usage of the STRTCPSVR SERVER(*FTP) 
command starts one additional FTP server. 


Note: Having more than one FTP server job 
running can improve the performance 
of initiating a session when multiple 
users attempt to connect to the server 
in a short period of time. 


*SMTP: The Simple Mail Transfer Protocol 
(SMTP) client and server jobs are started. 
Additional SMTP client and server jobs cannot 
be started. Subsequent usage of the 
STRTCPSVR SERVER(*SMTP) command 
results in a diagnostic message if the SMTP 
server jobs have already been started. 


*LPD: The line printer daemon (LPD) servers 
are started based on the number of servers 
configured with the Change LPD Attributes 
(CHGLPDA) command. Subsequent usage of 
the STRTCPSVR SERVER(*LPD) command 
starts one additional LPD server. 


Note: LPD works most efficiently when two 
or more servers are running. Running 
only one server works, but no jobs can 
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STRTCPSVR 


be received while a current job is 
running. If a large print job is running, 
new jobs have to wait before LPD is 
ready to accept any new line printer 
requester (LPR) requests. 


Examples 


Example 1: Starting all TCP/IP Servers 
STRTCPSVR 


This command starts all of the TCP/IP application 
servers that have been configured to be started. 
For example: If the Change FTP Attributes 
(CHGFTPA) command had previously been used 
to configure two FTP servers, both servers would 
be started when STRTCPSVR is issued. This 


example is also true for other TCP/IP application 
servers. 


Where appropriate, the number of servers to start 
is based on the number of servers configured for 
the server being started. The configuration option 
to automatically start the servers (AUTOSTART) is 
ignored by the STRTCPSVR command. The 
AUTOSTART parameter is used only by the 
STRTCP command. 


Example 2: Starting the TELNET Server 
STRTCPSVR SERVER(*TELNET) 


This command starts the TCP/IP TELNET applica- 
tion server. If the TELNET server had been previ- 
ously started, one additional TELNET server job 
would be started. 
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STRTRPMGR 


STRTRPMGR (Start Trap Manager) Command 


>>—STRTRPMGR 


Job: B,| Pgm: B,| REXX:B,l Exec 


a 
FWOTRP(——*YES—-—) 


>< 


Purpose 


The Start Trap Manager (STRTRPMGR) 
command allows you to start the OS/400 SNMP 
Manager Framework trap manager job. An 
optional Forward Trap parameter may be specified 
which enables traps that are received on other 
systems to be forwarded to other Network Man- 
agement stations. The trap manager uses the 
trap generation and sending facilities provided in 
the Simple Network Management Protocol 
(SNMP) agent and Distributed Protocol Interface 
(DPI) interface. 


Optional Parameters 


FWDTRP 
Specifies whether traps received on the 
system are to be forwarded to other network 
management stations. 


*YES: Received traps are forwarded using 
the facilities provided in the SNMP agent and 
DPI interface. 


*NO: Received traps are not forwarded. 
Traps are only enqueued. 


Examples 


Example 1: Start Trap Manager Job (Enqueue 
Traps Only) 


STRTRPMGR 


This command starts the trap manager job. Traps 
received by the trap manager are enqueued only. 


Example 2: Start Trap Manager Job (Enqueue 
& Forward Traps) 


STRTRPMGR FWDTRP(*YES) 
This command starts the trap manager job. Traps 


received by the trap manager are enqueued and 
forwarded. 


Appendix D. CL Commands for AS/400 SNMP. ~D-13 


RMVCOMSNMP 


RMVCOMSNMP (Remove Community for SNMP) Command 


Job: B,| Pgm: B,| REXX:B,Il Exec 


>>—RMVCOMSNMP—COM (—community-name—)—” 


Note: 


>< 


*YES 


ne ICOM( 


*NO ) 


P All parameters preceding this point can be specified in positional form. 


Purpose 


The Remove Community for SNMP 
(RMVCOMSNMP) command is used to remove a 
Simple Network Management Protocol (SNMP) 
community profile from the SNMP agent commu- 
nity list. The community profile consists of a com- 
munity name, an object access specification, and 
a list of the SNMP managers that are part of the 
community. The combination of the community 
name (COM) and the translate to ASCII commu- 


nity (ASCIICOM) parameters defines a community. 


Required Parameter 


COM 
Specifies the name of the SNMP community 
being removed. The community must already 
exist in the SNMP agent community list. 


community-name: Specify the name of the 
SNMP community being removed. The name 
may contain characters that cannot be dis- 
played. 


Optional Parameter 


ASCIICOM 
Specifies whether the community name is 
translated to ASCII characters before it is 
compared with the community name specified 
in a request from an SNMP manager. This 
parameter is used in combination with the 
community name to determine the community 
to be removed. If two communities have the 
same name and you don't specify the 
ASCIICOM parameter, the community with 
ASCIICOM set to *YES is removed. 


*YES: The community name is translated to 
ASCII characters before it is compared with a 
community name specified by an SNMP 
manager. 


*NO: The community name is not translated 
to ASCII characters before it is compared with 
a community name specified by an SNMP 
manager. 


Example 


RMVCOMSNMP = COM(ROCHESTER) 


This command removes community ROCHESTER 
from the SNMP agent community list. 
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networks. 


e¢ Backup and Recovery book, SC41-5304, provides 
information to help you become familiar with AS/400 
functions, develop a backup plan, and recover from 
system failures. 


¢ Communications Management, SC41-5406, con- 
tains information about operating communications 
and handling communications errors. 


¢ Communications Configuration, SC41-5401, con- 
tains general configuration information, including 
descriptions of network interface, line, controller, 
device, modes and class-of-service descriptions. 
Information about configuration lists and connection 
lists is also included. 


¢ CL Programming, SC41-5721, provides a dis- 
cussion of AS/400 programming topics, such as a 
general discussion of objects and libraries, control 
language (CL) programming, messages and 
message handling, user-defined commands and 
menus, and application testing. 


¢ CL Reference, SC41-5722, provides a description of 
the AS/400 control language (CL) and its com- 
mands. 


ILE C/400 Programmer's Guide, SC09-2069 and 
ILE C/400 Programmer's Reference book, 
SC09-2070, Provides information on how to develop 
applications using the ILE C/400 language. 

Includes information about creating, running and 
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debugging programs. Also includes programming 
considerations for interlanguage program and pro- 
cedure calls, locales, handling exceptions, data- 
base, externally described and device files. 


System API Reference: UNIX-Type APIs book, 
SC41-5875, and System API Reference: Client 
Support APIs book, SC41-5851, provide 
descriptions of the OS/400 application programming 
interfaces (APIs). 


¢ TCP/AP Configuration and Reference book, 
$C41-5420, provides information for configuring and 
using AS/400 TCP/IP support. The applications 
included are Network Status (NETSTAT), Packet 
InterNet Groper (PING), TELNET, File Transfer Pro- 
tocol (FTP), Simple Mail Transfer Protocol (SMTP), 
line printer requester (LPR), and line printer daemon 
(LPD). The TCP and UDP Pascal application 
program interface (API) is also discussed. 


NetView 


e Learning About NetView: Network Concepts, 

SK2T-0292 (PC Diskette) 

NetView Administration Reference, SC30-3361 

e NetView Command Lists, SC30-3423 

e¢ NetView Command Summary, SX27-3620 

e NetView Customization, LY30-5586 

e NetView Diagnosis, LY30-5587 

e NetView Hardware Problem Determination Refer- 
ence, SC30-3366 

e NetView Installation and Administration book, 
SC30-3360 

e NetView Messages, SC30-3365 

e NetView Operation, SC30-3364 

e NetView Operation Primer, SC30-3363 

e NetView Operation Scenarios, SC30-3376 

e Network Program Products Bibliography and Master 
Index, GC30-3353 

e Network Program Products General Information, 
GC30-3350 

e Network Program Products Planning, SC30-3351 

e Network Program Products Samples: NetView, 
$C30-3352 

e Network Program Products Storage Estimates, 
SC30-3403 


Advanced Communications 
Function for Virtual 
Telecommunications Access 
Method (ACF/VTAM) 


¢ ACF/VTAM* General Information, GC38-0254 
¢ ACF/VTAM System Programmer’s, SC38-0258 


Systems Network Architecture 
(SNA) 


Systems Network Architecture Technical Overview, 
GC30-3072 

Systems Network Architecture Formats, GA27-3136 
Systems Network Architecture Format and Protocol 
Reference, SC30-3112 

Systems Network Architecture-Sessions Between 
Logical Units, GC20-1868 


Non-IBM Publications 


Simple Network Management 
Protocol 


Case, J. D., Fedor, M. S., Schoffstall, M. L., and 
Davin, J. R. A Simple Network Management Pro- 
tocol. RFC 1157, SNMP Research, May 1990. 
Case, J. D., Davin, J. R., Fedor, J. R., and 
Schoffstall, M. L. Network Management and the 
Design of SNMP, ConneXions--The Interoperability 
Report, 3(3):22-26, March 1989, ISSN 0894-5926. 
Rose, M. T., and McCloghrie, K. Concise MIB Defi- 
nitions. RFC 1212, Performance Systems Interna- 
tional, Inc., March 1991. 

Rose, M. T. Network Management is Simple: You 
just need the "Right" Framework. |n Integrated 
Network Management, II, pages 9-25, IFIP WG 6.6, 
North Holland, April 1991. ISBN 0-444-89028-9. 
Rose, M. T. The Simple Book: An Introduction to 
Internet Management, Englewood Cliffs:P T R 
Prentice-Hall, 1994. 
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